Nakładki dostępności, znane też jako overlay-e, to widżety JavaScript dodawane do strony internetowej, które reklamują się jako automatyczne rozwiązanie zgodności z WCAG. Spójne dowody prawne i techniczne z ostatnich lat wskazują, że nakładki nie chronią przed pozwami konsumenckimi ani przed sankcjami administracyjnymi. W tym artykule znajdziesz omówienie najważniejszych spraw publicznych (Robles v. Domino's, ugoda FTC z accessiBe), wyjaśnienie techniczne dlaczego nakładki nie zmieniają tego, co widzi audyt i czytnik ekranu, oraz praktyczne kroki migracji dla sklepów, które już mają nakładkę zainstalowaną.
Typowa nakładka dostępności (accessiBe, UserWay, EqualWeb, AudioEye) ładuje na stronie skrypt JavaScript o wielkości od 80 do 200 kilobajtów. Skrypt wstrzykuje do DOM-u dodatkowy element pływający, zwykle w prawym dolnym rogu, oferujący zestaw przełączników: zmiana wielkości fontu, zwiększenie kontrastu, kursor, animacje, dyslektyczny font, tryb dla osób z padaczką.
Niektóre nakładki, w tym accessiBe, próbują dodatkowo "naprawiać" stronę automatycznie: generują brakujące atrybuty alt z analizy obrazu, dodają role ARIA na podstawie heurystyk, modyfikują strukturę DOM-u w czasie wykonania.
Kluczowe stwierdzenie: nakładki nie zmieniają kodu źródłowego sklepu. Pliki Liquid w motywie Shopify pozostają takie same. Skaner uruchomiony bezpośrednio na adresie URL strony (axe-core, WAVE, Lighthouse) raportuje te same naruszenia, co przed instalacją nakładki, ponieważ skaner widzi DOM serwerowy, nie zmodyfikowany przez nakładkę.
Federal Trade Commission, amerykański organ ochrony konsumentów, ogłosiła w styczniu 2025 r. ugodę z firmą accessiBe Inc., największym na świecie dostawcą nakładek dostępności. accessiBe zgodziła się zapłacić 1 milion USD i zaprzestać twierdzeń marketingowych sugerujących, że produkt sam w sobie zapewnia zgodność z WCAG lub z amerykańskim ADA.
Z perspektywy polskiego sprzedawcy istotne są trzy konsekwencje tej ugody:
- Marketing nakładek wyprzedza ich rzeczywistą skuteczność. To stanowisko federalnego organu, nie opinia branżowa.
- Nakładka nie zwalnia operatora strony z obowiązku konformności w kodzie źródłowym.
- Polskie organy nadzoru oraz polskie sądy mogą powołać się na to rozstrzygnięcie jako materiał porównawczy w sprawach dotyczących praktyk wprowadzających w błąd na podstawie ustawy z 23 sierpnia 2007 r. o przeciwdziałaniu nieuczciwym praktykom rynkowym (Dz.U. 2007 nr 171 poz. 1206).
Najstarsza i nadal cytowana sprawa to Robles v. Domino's Pizza LLC, sygn. 17-55504 w Sądzie Apelacyjnym Stanów Zjednoczonych dla 9. Okręgu, wyrok z 15 stycznia 2019 r. Guillermo Robles, niewidomy klient sieci pizzerii Domino's, pozwał za to, że ich strona internetowa i aplikacja mobilna były niedostępne dla osób z czytnikami ekranu.
Domino's argumentowało, że ADA (Americans with Disabilities Act z 1990 r.) nie obejmuje stron internetowych, ponieważ nie są fizycznymi miejscami publicznymi. Sąd 9. Okręgu odrzucił tę argumentację, uznając stronę internetową za przedłużenie fizycznego miejsca publicznego, do którego ADA Title III ma zastosowanie. Sąd Najwyższy USA odmówił przyjęcia sprawy do rozpoznania w październiku 2019 r., utrwalając wyrok jako obowiązujący w jurysdykcji 9. Okręgu.
Linia orzecznicza w sprawach dotyczących dostępności stron internetowych w USA pozostaje niejednolita między okręgami (np. 11. Okręg w Gil v. Winn-Dixie poszedł inną drogą), ale Robles pozostaje cytowany jako podstawowy wyrok, do którego odsyła zarówno orzecznictwo, jak i opracowania branżowe na temat zgodności stron z ADA.
Fundacja Widzialni, polski podmiot monitorujący dostępność cyfrową, od lat publicznie odradza stosowanie nakładek jako mechanizmu zgodności z WCAG, wskazując, że nakładki nie zmieniają kodu źródłowego strony i mogą wręcz utrudniać korzystanie z czytników ekranu. Aktualne stanowisko Fundacji oraz inne polskie publikacje na ten temat są dostępne na widzialni.org. Argument prawny pozostaje ten sam co w USA: organ nadzoru rynku oraz sąd cywilny oceniają stronę po tym, co dostarcza serwer, a nie po tym, co dorysuje skrypt nakładki w przeglądarce.
W zakresie nieuczciwych praktyk rynkowych podstawą do kwestionowania reklamy nakładek typu "100 procent zgodne" pozostaje w Polsce ustawa z 23 sierpnia 2007 r. o przeciwdziałaniu nieuczciwym praktykom rynkowym (Dz.U. 2007 nr 171 poz. 1206) oraz ustawa z 16 lutego 2007 r. o ochronie konkurencji i konsumentów (Dz.U. 2007 nr 50 poz. 331).
Z punktu widzenia technicznego, nakładki nie działają z czterech powodów:
axe-core, open-source'owe narzędzie od Deque używane jako silnik wielu profesjonalnych skanerów, analizuje DOM bezpośrednio z HTML serwerowego, bez wykonania JavaScript. Nakładka dodaje swoje elementy dopiero po wykonaniu skryptu w przeglądarce, więc nie wpływa na to, co widzi skaner.
To samo dotyczy raportów Lighthouse w Google PageSpeed Insights, raportów WAVE od WebAIM, raportów axe DevTools dla Chrome.
NVDA, JAWS, VoiceOver i TalkBack mają tryb "browse mode" (zwany też "virtual cursor"), w którym czytnik buduje własną reprezentację strony na podstawie semantycznego HTML, nie z wstrzykniętych przez nakładkę elementów. W tym trybie warstwa dorzucana przez nakładkę nie zmienia tego, co użytkownik czytnika faktycznie napotyka. Wyniki z corocznego WebAIM Screen Reader User Survey pokazują, że to właśnie ten tryb jest dominującą formą korzystania z czytnika.
Nakładka dodaje skrypt JavaScript do każdego załadowania strony, co podnosi czas wykonania i pogarsza Core Web Vitals. Dla sklepu Shopify, który stara się o badge Built for Shopify, jest to konkretna utrata punktów Lighthouse Performance. Skala spadku zależy od rozmiaru skryptu nakładki i pozostałej wagi strony, więc trzeba ją zmierzyć na konkretnym sklepie.
Nakładka modyfikuje CSS w czasie wykonania (zmienia kontrast, wielkość fontu, kursor). To może konfliktować z natywnymi animacjami CSS w motywie, generując efekty wizualne nieprzewidziane przez autora strony.
Trzeba uruchomić skan kodu źródłowego, niezależny od nakładki. AccessifyAI w Shopify App Store udostępnia bezpłatny skan dziesięciu stron z raportem WCAG 2.2 AA. Raport pokaże naruszenia widoczne dla skanera, czyli dla PFRON-u i Fundacji Widzialni.
Każde naruszenie z raportu trzeba naprawić w pliku Liquid lub CSS motywu Shopify, nie przez ustawienia nakładki. AccessifyAI generuje ujednolicone diffy dla około 80 procent naruszeń. Pozostałe 20 procent (głównie kontekstowe, jak sens tekstu alt) wymaga decyzji człowieka.
Po naprawie naruszeń w kodzie źródłowym nakładkę można odinstalować. Sklep zachowuje zgodność z WCAG i dodatkowo odzyskuje punkty Lighthouse Performance utracone na skrypcie nakładki oraz oszczędza miesięczną opłatę abonamentową, której konkretną wysokość określa cennik danego dostawcy.
Art. 32 ust. 2 pkt 1 ustawy z 2024 r. wymaga, by usługodawca podał do publicznej wiadomości w regulaminie lub innym równoważnym dokumencie opis usługi, informacje niezbędne do korzystania z niej oraz informację, w jaki sposób usługa spełnia wymagania dostępności. Art. 33 doprecyzowuje szczegóły dotyczące pomieszczeń użyteczności publicznej i posiadanego certyfikatu dostępności. Dodatkowo art. 7 ust. 1 lit. b dyrektywy 2019/882 (EAA) wymaga mechanizmu zgłaszania barier, którym w praktyce jest aktywnie monitorowany e-mail kontaktowy.
| Argument marketingowy |
Rzeczywistość |
| "100 procent zgodne z WCAG" |
Ugoda FTC z accessiBe ze stycznia 2025 r. wymusiła wycofanie tego typu twierdzeń pod karą 1 mln USD |
| "Ochrona przed pozwami ADA" |
Robles v. Domino's pokazało, że obowiązek zgodności ciąży na operatorze strony niezależnie od narzędzi pomocniczych |
| "Jedno kliknięcie do zgodności" |
Skaner widzi naruszenia takie same jak przed instalacją, bo nakładka nie zmienia kodu źródłowego |
| "AI automatycznie naprawia teksty alt" |
Generowanie alt-tekstu z obrazu wymaga zrozumienia kontekstu i intencji autora, więc automatyczne propozycje wymagają ludzkiej rewizji |
| "Wsparcie dla każdego rodzaju niepełnosprawności" |
Stanowiska organizacji środowiskowych (np. NFB, Fundacja Widzialni) wskazują, że nakładki utrudniają korzystanie z czytników ekranu |
Nie. Wszystkie nakładki technicznie działają tak samo: wstrzykują skrypt JavaScript w czasie wykonania. Żadna z nich nie zmienia kodu źródłowego strony. To oznacza, że żadna nie obroni przed sankcją PFRON-u ani pozwem konsumenckim, w którym strona dowodowa opiera się na skanie kodu źródłowego.
Niektóre funkcje nakładek (przełącznik kontrastu, powiększenie fontu) mogą subiektywnie pomagać niewielkiej części użytkowników. Te same funkcje są jednak dostępne natywnie w przeglądarce (Ctrl + plus dla zoomu, Reader Mode w Firefox) i w systemach operacyjnych (High Contrast Mode w Windows, Increase Contrast w macOS). Wymuszanie ich przez nakładkę często konfliktuje z natywnymi ustawieniami użytkownika.
Tak, w trybie art. 415 Kodeksu cywilnego (ogólna odpowiedzialność deliktowa: "Kto z winy swej wyrządził drugiemu szkodę, obowiązany jest do jej naprawienia"), jeśli reklama nakładki wprowadzała Państwa w błąd co do skuteczności prawnej. Precedensem na rynku amerykańskim jest ugoda administracyjna FTC z accessiBe ze stycznia 2025 r. W Polsce nie zapadł jeszcze taki wyrok, ale podstawa prawna istnieje w art. 12 ust. 1 ustawy z 23 sierpnia 2007 r. o przeciwdziałaniu nieuczciwym praktykom rynkowym (Dz.U. 2007 nr 171 poz. 1206), który daje konsumentowi prawo żądania m.in. zaniechania praktyki, usunięcia jej skutków i naprawienia szkody. Równolegle Prezes UOKiK może wszcząć postępowanie z art. 24 ustawy z 16 lutego 2007 r. o ochronie konkurencji i konsumentów (Dz.U. 2007 nr 50 poz. 331), jeżeli praktyka narusza zbiorowe interesy konsumentów.
Shopify Plus, najwyższy plan Shopify dla dużych marek, nie różni się od innych planów pod kątem stosowalności nakładek. Te same argumenty prawne i techniczne odnoszą się do Shopify Plus. Większe marki mają zwykle większą ekspozycję na pozwy zbiorowe i większe ryzyko reputacyjne.
Nie. AccessifyAI nie wstrzykuje JavaScript do strony klientów. AccessifyAI skanuje stronę z zewnątrz (jak każdy audytor), identyfikuje naruszenia i zapisuje poprawki bezpośrednio w plikach Liquid i CSS motywu Shopify przez oficjalne Shopify Asset API. Po wdrożeniu poprawek AccessifyAI nie zostawia żadnego śladu na stronie klientów, nie ma żadnego pływającego widżetu, nie ma żadnego skryptu w runtime. Wszystkie zmiany są widoczne w kodzie źródłowym i przeżywają blokowanie skryptów.
W planie Pro AccessifyAI udostępniamy opcjonalny widżet dostępności w sklepie. To jest mały, lazy-ładowany komponent (16 kilobajtów), który dodaje przyciski zmiany kontrastu i wielkości fontu, podobnie jak nakładka. Ważne: widżet ten nie jest reklamowany jako rozwiązanie zgodności WCAG. To dodatek użytkowy dla osób, które wolą bezpośredni przełącznik na stronie zamiast ustawień przeglądarki. Sklep zachowuje zgodność WCAG przez poprawki w kodzie źródłowym, nie przez widżet.
Pełny czas migracji zależy od liczby i charakteru naruszeń w kodzie źródłowym Twojego motywu i zainstalowanych aplikacji. Pierwszą orientację daje skan automatyczny, który pokazuje, ile naruszeń jest do zaadresowania niezależnie od warstwy nakładki. Korzyść finansowa z odinstalowania nakładki to suma odzyskanych punktów Lighthouse Performance i miesięcznej opłaty abonamentowej, której konkretną wysokość określa cennik danego dostawcy nakładki.
Nakładki dostępności (overlay) nie chronią polskich sklepów online przed pozwami konsumenckimi ani przed sankcjami administracyjnymi. Najmocniejszy publiczny dowód po stronie regulatora to styczniowa 2025 r. ugoda FTC z accessiBe (1 milion USD i zakaz dalszego stosowania twierdzeń o "zgodności z WCAG/ADA"). Po stronie technicznej fakt, że automatyczny skaner widzi te same naruszenia po instalacji nakładki, co przed nią, nie zostawia miejsca na argument "mam nakładkę, więc jestem zgodny". Pragmatyczna ścieżka dla sklepu, który ma już nakładkę, to skan kodu źródłowego, naprawa naruszeń w plikach motywu, opublikowanie deklaracji dostępności i dopiero potem odinstalowanie nakładki.