Zweryfikowana broszura informacyjna: Nasze dowody techniczne potwierdzające każde twierdzenie

Społeczność zajmująca się dostępnością od lat ostrzega przed narzędziami typu overlay. Przeanalizowaliśmy ruch produkcyjny z czterech takich narzędzi i odniesiliśmy nasze ustalenia do poszczególnych twierdzeń zawartych w arkuszu informacyjnym dotyczącym narzędzi typu overlay – dostarczając tym samym techniczne dowody potwierdzające każde z ostrzeżeń.

Czym jest arkusz informacyjny dotyczący nakładki?

Dokument „Overlay Fact Sheet” to opracowany przez społeczność dokument podpisany przez ponad 600 specjalistów ds. dostępności – w tym autorów i redaktorów specyfikacji WCAG, ARIA i HTML oraz wewnętrznych ekspertów ds. dostępności z takich firm jak Google, Microsoft, Apple, Shopify, eBay i Target. Zawiera on szereg konkretnych stwierdzeń dotyczących ograniczeń i zagrożeń związanych z narzędziami nakładkowymi służącymi do sprawdzania dostępności.

Nasze badania – obejmujące 924 przechwycone żądania HTTP z 579 pełnymi treściami odpowiedzi z 14 działających witryn e-commerce, a także zapisane migawki DOM z wbudowanymi modyfikacjami nakładek – stanowią pierwszy obszerny zbiór dowodów technicznych pozwalający zweryfikować każde twierdzenie w oparciu o rzeczywiste dane produkcyjne. Oto, co odkryliśmy.

Twierdzenie 1: „Nakładki nie naprawiają kodu bazowego”

W arkuszu informacyjnym dotyczącym nakładek stwierdzono, że nakładki umożliwiają „tymczasowe modyfikacje interfejsu użytkownika”, a nie trwałe zmiany w kodzie źródłowym.

Nakładka A ładuje pliki poprawek JavaScript dla poszczególnych witryn, zawierające 1 023 defineFix reguły, które wykorzystują setAttribute, attr()oraz hideFromAT() w celu modyfikowania elementów DOM w czasie wykonywania. Jeśli skrypt nakładki zostanie usunięty lub nie uda się go załadować, wszystkie poprawki znikną natychmiast – kod bazowy pozostaje niezmieniony.

Overlay B pobiera plik JSON z poprawkami o rozmiarze 1,17 MB i wdraża je za pomocą oddzielnego modułu naprawczego. Poprawki są przypisane do konkretnych adresów URL obrazów – po usunięciu nakładki wszystkie 5 068 wpisów tekstu alternatywnego znika. Obrazy ponownie nie zawierają żadnego tekstu alternatywnego.

Nakładka C zawiera monolityczny pakiet o rozmiarze 794 KB, który modyfikuje DOM za pomocą 227 setAttribute wywołań, 82 modyfikacje ról i 128 aria-label skrypty. Żaden z nich nie modyfikuje kodu HTML po stronie serwera.

Nakładka D stosuje nazwy oparte na konfiguracji za pomocą silnika o rozmiarze 649 KB z 216 setAttribute wywołania. Poprawki działają tylko tak długo, jak długo silnik jest uruchomiony.

Natomiast narzędzie monitorujące w ogóle nie naprawia błędów – zgłasza je jedynie do panelu programisty. Programiści naprawiają je w kodzie źródłowym, gdzie poprawki są trwałe, testowane i wdrażane za pośrednictwem standardowych procesów CI/CD.

Co się stanie, gdy sieć CDN typu overlay przestanie działać?

Z arkusza informacyjnego wynika, że poprawki nakładkowe mają charakter tymczasowy. Możemy dokładnie określić, na jak długo: jeśli sieć CDN obsługująca skrypt JavaScript nakładki przestanie działać, wszystkie poprawki znikną natychmiast. Nasze dane pokazują łańcuch zależności:

Nakładka A: W odniesieniu do poszczególnych witryn active.js (do 238 KB) ładuje się z jednej sieci CDN. Jeśli dostęp do tej sieci CDN zostanie utracony nawet na 30 sekund, żadna strona załadowana w tym czasie nie otrzyma poprawek dotyczących dostępności. 1023 reguły poprawek, 35 pułapek fokusowych w oknach modalnych oraz wszystkie wstawione etykiety ARIA po prostu znikają.

Warstwa B: Silnik naprawczy opiera się na trzech zewnętrznych usługach: sieci CDN dla skryptów, interfejsie API do dostosowań i konfiguracji oraz oddzielnej sieci CDN dla interfejsu API generującego alternatywne opisy tekstowe za pomocą sztucznej inteligencji. Jeśli którakolwiek z tych trzech usług ulegnie awarii, dochodzi do zakłóceń w różnych częściach procesu naprawy – co może spowodować, że model DOM pozostanie w stanie częściowo zmodyfikowanym, w którym niektóre poprawki zostały zastosowane, a inne nie.

Nakładka C: Cała nakładka stanowi pojedynczy pakiet o rozmiarze 794 KB pochodzący z jednej domeny. Awaria sieci CDN = całkowite zniknięcie widżetu. Ponieważ jednak obiekt MutationObserver nakładki monitorował DOM i modyfikował elementy, częściowe załadowanie strony – w którym obserwator został zainicjowany, ale logika naprawcza nie została zakończona – mogło spowodować, że DOM znalazł się w stanie niespójnym.

Narzędzie do monitorowania nie jest w żaden sposób uzależnione od sieci CDN pod względem dostępności. W przypadku awarii sieci CDN jedyną konsekwencją jest zaprzestanie rejestrowania statystyk dotyczących odwiedzin strony. Nie ma to wpływu na dostępność witryny, ponieważ wszystkie poprawki znajdują się w kodzie źródłowym – nie są one uzależnione od ładowania skryptów stron trzecich.

Twierdzenie 2: „Nie da się osiągnąć pełnej zgodności przy użyciu nakładki”

W arkuszu informacyjnym stwierdzono, że „udokumentowana niemożność tych produktów do usunięcia wszystkich potencjalnych problemów oznacza, że nie są one w stanie zapewnić zgodności strony internetowej z przepisami”.

Konkretne przypadki nieprzestrzegania przepisów, które odnotowaliśmy:

WCAG 1.1.1 (Treści nietekstowe): Nakładka B generuje tekst alternatywny AI, który nie spełnia kryterium „równoważnego przeznaczenia” – logo firmy opisane jako „niebiesko-żółty znak”, ikona nawigacyjna opisana jako „prosty czarny prostokąt”. 241 wpisów miało mniej niż 15 znaków. 323 przekraczało 125 znaków.

WCAG 2.1.1 (Klawiatura): Nakładka A ukrywa elementy interaktywne w drzewie dostępności, uniemożliwiając dostęp do nich za pomocą klawiatury. Przyciski płatności, elementy sterujące koszykiem oraz linki wyników wyszukiwania ukryte przez hideFromAT() nie można na nim ustawić fokusu ani obsługiwać go za pomocą klawiatury.

WCAG 4.1.2 (Nazwa, rola, wartość): Overlay A wprowadza aria-label="true" w 7 elementach w 3 lokalizacjach – błąd w kodzie, w którym nazwą dostępową jest pozbawiony znaczenia ciąg znaków „true”. Nakładka A również ma zastosowanie role="presentation" do 115 elementów, pozbawiając tabele, nagłówki i punkty orientacyjne znaczenia semantycznego.

WCAG 1.3.1 (Informacje i powiązania): Kiedy role="presentation" gdy zostanie zastosowany do tabeli danych, czytniki ekranu nie będą już mogły poruszać się po wierszach i kolumnach. Struktura tabeli znika z drzewa dostępności.

Przyporządkowaliśmy 776 reguł poprawek nakładki A do konkretnych kryteriów sukcesu WCAG. Z tego zestawienia wynika paradoks zgodności nakładek:

Najbardziej niepokojąca sekcja dotyczy WCAG 1.1.1 (Treści nietekstowe): spośród 108 zasad dotyczących poprawek odnoszących się do tego kryterium, 80 jest szkodliwych – Całkowicie ukryj 52 obrazy z serwisu AT za pomocą hideFromAT()oraz 28 oznaczają obrazy treści jako elementy dekoracyjne za pomocą alt="". Nakładka sprawia, że treści inne niż tekst mniej dostępne, nic więcej. Jest to dokładne przeciwieństwo tego, czego wymagają wytyczne WCAG 1.1.1.

Federalna Komisja Handlu Stanów Zjednoczonych potwierdziła tę ocenę, nakładając w kwietniu 2025 r. na jednego z dostawców nakładek karę w wysokości 1 miliona dolarów i stwierdzając, że narzędzie to „nie zapewnia lub nie zapewniało zgodności podstawowych i niezbędnych elementów stron internetowych, takich jak menu, nagłówki, tabele, obrazy, nagrania i inne, z wytycznymi WCAG”.

Twierdzenie 3: „Nakładki mogą tworzyć nowe bariery w dostępności”

W arkuszu informacyjnym ostrzega się, że produkty nakładkowe mogą „stanowić aktywną przeszkodę dla osób niepełnosprawnych”.

Najbardziej szkodliwe przykłady dotyczą procesów realizacji transakcji i koszyka:

W jednym z luksusowych sklepów internetowych przyciski Amazon Pay, Shop Pay i Klarna są niedostępne dla technologii wspomagających. Niewidomy użytkownik podczas finalizacji zamówienia widzi mniej opcji płatności niż osoba widząca. W sklepie z odzieżą pola wprowadzania ilości produktów w koszyku oraz przyciski aktualizacji są ukryte – niewidomy użytkownik nie może zmodyfikować swojego zamówienia.

Linki do wyników wyszukiwania produktów są ukryte na dwóch stronach – utrudnia to osobom niewidomym znalezienie produktów. Oceny gwiazdkowe są ukryte – osoby niewidome nie mogą ocenić jakości produktów w taki sam sposób, jak osoby widzące.

Federalny organ nadzorczy Niemiec (BFIT-Bund) potwierdził tę tendencję w swojej oficjalnej wspólnej ocenie: „Często zdarza się, że stosowanie takich narzędzi powoduje powstanie dodatkowych barier na stronie internetowej, które nie istniałyby bez nich”.

Twierdzenie 4: „Użytkownicy będą już dysponować potrzebnymi narzędziami”

W arkuszu informacyjnym stwierdzono, że „użytkownicy końcowi, którym te funkcje rzekomo mają służyć, będą już dysponować niezbędnymi funkcjami na swoich komputerach”.

Gdy użytkownik czytnika ekranu skonfiguruje skróty klawiaturowe i preferencje nawigacji, wyświetla się nakładka, która przechwytuje keydown, keyuporaz keypress zdarzenia mogą zastąpić te ustawienia. 47 odwołań do zdarzeń klawiatury w pakiecie Overlay C o rozmiarze 794 KB stanowi znaczną powierzchnię przechwytywania zdarzeń klawiatury. Silnik Overlay D zawiera 282 addEventListener rejestracje – z których każda może kolidować z procedurami obsługi zdarzeń technologii wspomagających.

Twierdzenie 5: „Wartość praktyczna” widżetów nakładkowych jest znacznie przeceniana

W arkuszu informacyjnym stwierdzono, że funkcje widgetów, takie jak regulacja kontrastu i rozmiaru tekstu, mają ograniczoną wartość, ponieważ użytkownicy mają już do dyspozycji odpowiedniki na poziomie systemu.

Najgorsza strona z nakładką B wygenerowała 48 żądań, co zajęło 12,8 sekundy czasu sieciowego. Dla porównania: próg Google w ramach wskaźników Core Web Vitals dla „słabego” wyniku Largest Contentful Paint wynosi 2,5 sekundy. Sama nakładka przekroczyła ten limit pięciokrotnie.

Overlay A poświęcił 75% ze swoich 33,9 sekund czasu sieciowego na analizę behawioralną – wysyłając 58 żądań POST do własnego punktu końcowego. Żądania CDN związane z dostępnością zajęły jedynie 25% całkowitego czasu. Większość obciążenia wydajnościowego wynika z gromadzenia danych przez dostawcę, a nie z poprawy dostępności.

Twierdzenie 6: „Właściciele stron powinni stosować solidniejsze, niezależne i długoterminowe strategie”

W niniejszym zestawieniu informacji zaleca się „rezygnację z tymczasowych nakładek ułatwiających dostępność stron internetowych” na rzecz trwałych strategii w zakresie dostępności.

Z naszych danych wynika, że podstawowa różnica ma charakter architektoniczny: nakładki utrzymują równoległy zestaw definicji poprawek, który odzwierciedla strukturę DOM strony i traci aktualność przy każdym wdrożeniu. Narzędzie monitorujące skanuje strukturę DOM istniejącą w momencie skanowania, generuje raport na podstawie znalezionych elementów, a przy kolejnym skanowaniu zaczyna od nowa. Nie gromadzi się dłuż techniczny, nie ma nieaktualnych selektorów ani osieroconych wpisów tekstu alternatywnego, a także nie ma możliwości zastosowania niewłaściwej poprawki do niewłaściwego elementu.

Więcej niż tylko zestawienie faktów: co wnoszą nasze dane

Nasze badania ujawniły wyniki wykraczające poza zakres arkusza informacyjnego Overlay:

Niezgodność z PCI DSS 4.0: Reguły poprawek nakładek aktywnie skupiają się na elementach strony płatności – udokumentowaliśmy selektory dla #cardNumber, #billingState, przyciski płatności i formularze realizacji transakcji. Zgodnie z wymogiem 6.4.3 standardu PCI DSS (obowiązującym od marca 2025 r.) każdy skrypt strony płatności wymaga udokumentowanej weryfikacji autoryzacji i integralności. Nakładki nie spełniają tego wymogu. W przypadku jednej grupy zajmującej się sprzedażą dóbr luksusowych identyczne selektory kierujące do stron płatności są wspólne dla dwóch witryn marek (96% pokrycia kodu źródłowego), co podwaja zasięg skutków ewentualnego naruszenia bezpieczeństwa w łańcuchu dostaw.

Częstotliwości próbkowania skanowania już od 1,7%: Odkryliśmy, że dane analityczne POST jednej nakładki zawierają samplingRate Dane wskazują, że jedynie 1,7–4,5% sesji powoduje uruchomienie skanowania zgodności. Pozostałe 95–98% otrzymuje poprawki DOM bez żadnej weryfikacji.

Naruszenia RODO: Trzy nakładki przesyłają identyfikatory użytkowników, dane dotyczące odcisków palców urządzeń oraz dane analityczne dotyczące zachowań, zanim uruchomi się jakikolwiek mechanizm uzyskiwania zgody – co stanowi automatyczne naruszenie przepisów zgodnie z orzeczeniem Trybunału Sprawiedliwości UE w sprawie Planet49. Jedna z nakładek przesyła trwały identyfikator UUID, który pozostaje niezmienny przy każdym ładowaniu strony, umożliwiając tworzenie kompletnych profili przeglądania obejmujących wszystkie strony.

Odmowa ze strony niemieckich organów regulacyjnych: Federalny Urząd ds. Technologii Informacyjnych (BFIT-Bund) oficjalnie odrzucił stosowanie nakładek w ramach testów zgodności, a jednostki certyfikujące BIK odmawiają wydawania certyfikatów zgodności stronom internetowym korzystającym z nakładek. Zgodnie z niemiecką ustawą BFSG (transpozycja dyrektywy EAA) kary wynoszą od 10 000 do 100 000 euro za każde naruszenie.

Wstrzykiwanie etykiet w formularzach podczas działania, które pogarsza ich działanie: Moduł naprawczy nakładki (110 KB) stosuje w czasie wykonywania 24 reguły modyfikacji DOM, w tym procedurę obsługi EmptyControls, która próbuje nadać etykiety nieoznaczonym polom formularza. W przypadku działającego formularza kontaktowego zawierającego siedem pól moduł ten wstawił aria-label wartości pobrane z kodu HTML name atrybut zamiast widocznych etykiet – co powoduje, że dwa pola mają tę samą etykietę „Nazwa” (z name="first-name" oraz name="last-name"), trzy pola oznaczone ogólnymi typami elementów („Pole tekstowe”, „Pojedynczy wybór”, „Obszar tekstowy”) oraz dwa pola, w których zamiast rzeczywistych etykiet widocznych zastosowano opisy typów walidacji. Zapisana migawka DOM potwierdza, że każdy zmodyfikowany element zawiera specyficzny dla dostawcy znacznik atrybutu danych nakładki. Oryginalny kod HTML zawierał poprawne etykiety widoczne („Imię”, „Nazwa firmy” itp.), ale brakowało im for atrybuty – prosta poprawka w kodzie źródłowym, której silnik wykonawczy nakładki nie zdołał poprawnie odtworzyć.

Poprawianie pliku JSON zanieczyszczonego treściami z obcych domen: gotowy plik JSON do poprawiania, przeznaczony dla serwisu bankowego, zawierał 7 wpisów tekstu alternatywnego – z czego tylko 1 faktycznie pochodził z domeny samego banku (z tekstem alternatywnym składającym się z pojedynczej spacji). Pozostałe 6 wpisów opisywało obrazy z zupełnie niepowiązanych domen: polskiego narzędzia do testowania dostępności (ikony skryptów ANDI), chińskiego API do porównywania cen (ikony widgetów czatu), rosyjskiej sieci reklamowej typu teaser (kreacje reklamowe) oraz przeglądarkowego CDN firmy Xiaomi (interfejs użytkownika z monitem o tłumaczenie). Skaner nakładki przechwycił je podczas poprzedniej sesji, w której osoba przeglądająca stronę miała aktywne rozszerzenia przeglądarki innych firm oraz wstrzykiwanie reklam – i trwale zapisał opisy wygenerowane przez AI w pliku naprawczym banku, pobieranym przez każdego odwiedzającego na każdej stronie. Plik JSON jest publicznie dostępny w sieci CDN nakładki bez konieczności uwierzytelniania.

Ostrzeżenia zawarte w arkuszu informacyjnym „Overlay”, opracowanym przez specjalistów ds. dostępności w oparciu o ich doświadczenie, znalazły obecnie potwierdzenie w danych produkcyjnych zebranych z 14 działających witryn e-commerce. Każde z głównych stwierdzeń okazuje się prawdziwe – a rzeczywista sytuacja w wielu obszarach jest gorsza niż opisano w arkuszu informacyjnym.

Twierdzenie 7: „Nakładki podważają uzasadnione działania na rzecz dostępności”

W dokumentacji dotyczącej „fałszywych twierdzeń” związanych z nakładkami ostrzega się, że nakładki tworzą „fałszywy obraz sytuacji, jakby problem dostępności został rozwiązany” oraz że są one „sprzeczne z podstawowymi założeniami ustawy ADA”.

Głębszym problemem jest to, że nakładki zmieniają sposób myślenia z „musimy tworzyć produkty dostępne dla wszystkich” na „zainstalowaliśmy narzędzie, które zajmuje się dostępnością”. Nasze dane pokazują, jak to wygląda w praktyce: pewien sprzedawca designerskich torebek ma w swojej nakładce 383 reguły poprawiające – jednak w bazowym kodzie HTML nadal występują wszystkie pierwotne problemy związane z dostępnością. Jeśli sieć CDN dostawcy nakładki przestanie działać na 30 minut, wszystkie bariery natychmiast powracają. Witryna nigdy nie została naprawdę naprawiona.

Twierdzenie 8: Obawy dotyczące prywatności i śledzenia

Chociaż kwestia ta nie stanowi głównego tematu arkusza informacyjnego dotyczącego nakładek, obrońcy praw osób niepełnosprawnych zgłaszają obawy dotyczące prywatności, zwracając uwagę, że nakładki mogą wykrywać korzystanie z technologii wspomagających.

Nakładka A: 58 żądań POST do własnego punktu końcowego na sesję, z których każde zawiera identyfikator sesji (sid), pełny adres URL strony (pg), identyfikator ładowania strony (plid), kategorię urządzenia oraz typ zdarzenia. 75% całkowitego czasu pracy sieci poświęcone jest na te wywołania śledzące.

Warstwa nakładkowa B: Trwały identyfikator UUID (uid) wysyłany w każdym żądaniu POST – ten sam identyfikator na wszystkich stronach w ramach sesji, co pozwala dostawcy stworzyć kompletny profil przeglądania. UUID pozostaje niezmienny – zaobserwowaliśmy, że nie zmieniał się on na żadnej z pięciu stron jednej witryny telekomunikacyjnej.

Nakładka C: USER-BEHAVIOR-ANALYTICS Przesyłaj dane, w tym nazwę domeny, wersję widżetu oraz zdarzenia interakcji. Identyfikacja urządzeń za pomocą navigator.userAgent, navigator.userAgentDataoraz navigator.maxTouchPoints. Trzy localStorage klucze zachowujące stan między sesjami.

Wszystkie trzy uruchamiają śledzenie po załadowaniu strony – zanim zdąży zadziałać jakikolwiek mechanizm uzyskiwania zgody. Zgodnie z orzeczeniem TSUE w sprawie Planet49 śledzenie, które nie jest niezbędne, wymaga uprzedniej zgody użytkownika. Te nakładki automatycznie naruszają przepisy RODO na każdej stronie skierowanej do użytkowników z UE.

Twierdzenie 9: „Nakładki wiążą się z ryzykiem prawnym”

W zestawieniu informacji zaznaczono, że nakładki nie są w stanie „wyeliminować ryzyka prawnego”, mimo zapewnień dostawców.

Nasza baza danych spraw sądowych (8 541 akt spraw dotyczących ADA) zawiera informacje o bezpośrednich sporach sądowych z udziałem dostawców nakładek: trzy sprawy dotyczące patentów/tajemnic handlowych między dwoma dostawcami (2020–2022), pozew zbiorowy wniesiony przez klienta przeciwko jednemu dostawcy (2024) oraz toczący się proces przeciwko innemu dostawcy, wniesiony przez małą firmę, która została pozwana pomimo korzystania z nakładki (2024, wniosek o oddalenie sprawy odrzucony przez sędziego pokoju w 2026 r.).

Narzędzie do monitorowania nie ma na koncie żadnych sporów sądowych związanych z naruszeniami zasad dostępności – co jest logicznym następstwem: ponieważ nie modyfikuje ono modelu DOM, nie może powodować barier, które mogłyby stać się przyczyną pozwów sądowych.

Luka w dowodach została wypełniona

Przez lata zestawienia dotyczące nakładek oraz ostrzeżenia społeczności zajmującej się dostępnością opierały się na doświadczeniu zawodowym, zgłoszeniach użytkowników i testach ręcznych. Krytycy mogli je lekceważyć jako anegdotyczne lub stronnicze. Nasze badania wypełniają tę lukę, dostarczając pierwsze dowody techniczne na dużą skalę: przechwycone dane produkcyjne z 924 żądań sieciowych, 579 wyodrębnionych plików źródłowych z 14 działających witryn e-commerce podczas trzech niezależnych sesji przechwytywania, uzupełnione zapisanymi migawkami DOM, które zachowują dokładne modyfikacje wprowadzane w czasie wykonywania przez nakładki na stronach produkcyjnych.

Każde istotne stwierdzenie zawarte w arkuszu informacyjnym Overlay znajduje potwierdzenie w naszych danych. Niektóre z tych stwierdzeń są nawet zaniżone w stosunku do naszych ustaleń. Natomiast kwestie, których arkusz informacyjny nie porusza – sprzeczności z PCI DSS, częstotliwość próbkowania podczas skanowania, śledzenie użytkowników przed wyrażeniem zgody zgodnie z RODO oraz odrzucenie przez niemieckie organy regulacyjne – stanowią dodatkowe wymiary ryzyka, które społeczność zajmująca się dostępnością zidentyfikowała na podstawie doświadczeń, ale których wcześniej nie była w stanie oszacować.

Dowody znajdują się w kodzie. Kod znajduje się w przechwyconym ruchu sieciowym. Ruch ten pochodzi z serwisów produkcyjnych obsługujących prawdziwych klientów. Wyniki mówią same za siebie.