Nakładki dostępności: czy są bezpieczne prawnie?

Co to jest nakładka dostępności?

Nakładka dostępności to widżet JavaScript — wczytywany za pomocą skryptu firmy trzeciej — który nakłada się na istniejącą witrynę i twierdzi, że czyni ją bardziej dostępną. Większość nakładek prezentuje mały ikonę (postać w kółku lub symbol wózka inwalidzkiego), która otwiera panel kontrolek: zmianę rozmiaru czcionki, przełączanie wysokiego kontrastu, włączenie „trybu czytnika ekranu” lub zastosowanie czcionek przyjaznych dla dysleksji.

Dostawcy nakładek reklamują swoje produkty jako proste, szybkie i niskokosztowe rozwiązanie na drodze do zgodności z WCAG i ochrony prawnej przed ADA. Przekaz jest przekonujący: zainstaluj jeden tag skryptu, płać miesięczną opłatę, a problem z dostępnością zostanie rozwiązany.

Dowody — z badań akademickich, niezależnych testów, opinii użytkowników i sądów — opowiadają zupełnie inną historię.

Jak działają nakładki (i dlaczego to tworzy problemy)

Nakładki działają poprzez przechwytywanie wyrenderowanego DOM po tym, jak przeglądarka przetworzyła stronę, i nakładanie modyfikacji sterowanych JavaScriptem. Niektóre wykorzystują uczenie maszynowe, próbując automatycznej naprawy: wywnioskowania brakującego tekstu alternatywnego z nazw plików obrazów, odgadywania etykiet ARIA, próby zmiany kolejności fokusu klawiaturowego.

Takie podejście ma podstawowy problem architektoniczny: próbuje naprawić niedostępność na warstwie prezentacji, bez zmiany leżącego pod nią kodu. Pierwotny niedostępny HTML, CSS i JavaScript pozostają nienaruszone. Nakładka próbuje je zatuszować w czasie działania.

Konsekwencje są przewidywalne:

• Poprawki zastosowane przez nakładkę mogą wchodzić w konflikt ze sposobem, w jaki technologie wspomagające interpretują natywny DOM, prowadząc do gorszych rezultatów niż na stronie bez poprawek
• Czytniki ekranu wchodzą w interakcję z DOM bezpośrednio — warstwa nałożona na niego może nie mieć wpływu na to, co czytnik ekranu faktycznie odczytuje
• Problemy z nawigacją klawiaturą wynikające z brakującego tabindex lub uszkodzonego zarządzania fokusem nie są wiarygodnie korygowane przez łatki JavaScript zastosowane po wyrenderowaniu
• Mobilne technologie wspomagające (VoiceOver w iOS, TalkBack w Androidzie) w dużej mierze omijają modyfikacje nakładki
• Same panele nakładek często zawierają błędy dostępności — okna modalne przechwytujące fokus klawiaturowy, przyciski bez dostępnych nazw, widżety, które same są niedostępne z klawiatury

Co pokazują badania

Wiele niezależnych badań przetestowało twierdzenia dostawców nakładek wobec rzeczywistej zgodności z WCAG:

The WebAIM Million (2023) wykazało, że strony główne witryn korzystających z produktów typu nakładka miały znacznie więcej wykrywalnych błędów WCAG niż te, które ich nie używały. Nakładki nie zmniejszyły wskaźnika błędów — skorelowały się z jego wzrostem, najpewniej dlatego, że organizacje traktujące nakładki jako główną strategię zgodności nie prowadzą leżącej pod nimi pracy naprawczej.

Audyty AccessiBe i UserWay przeprowadzone przez badaczy dostępności wykazały, że nawet po włączeniu nakładki strony wciąż nie spełniają istotnej części kryteriów sukcesu WCAG 2.1 poziomu AA — w tym błędów, które nakładka wprost obiecuje naprawić.

Testy z udziałem użytkowników z niepełnosprawnościami przeprowadzone przez badaczy, w tym Karla Grovesa i Adriana Roselliego, wykazały, że wielu użytkowników z niepełnosprawnościami aktywnie wyłącza lub blokuje widżety nakładek, ponieważ interwencje te pogarszają ich doświadczenie, a nie poprawiają. „Tryb czytnika ekranu” nakładki jest szczególnie często wskazywany jako destrukcyjny przez użytkowników czytników ekranu, którzy już skonfigurowali swoją technologię wspomagającą pod swoje potrzeby.

Organizacja branżowa, którą nakładki twierdzą, że satysfakcjonują — W3C — nie zatwierdziła technologii nakładek jako drogi do zgodności z WCAG. Wytyczne W3C jasno stanowią, że zgodność wymaga, aby sama strona spełniała kryteria sukcesu, a nie warstwa modyfikacji firmy trzeciej nałożona na nią.

Co mówią sądy

Zapis prawny dotyczący nakładek jest coraz bardziej niekorzystny dla organizacji, które traktują je jako swoją główną strategię zgodności.

Pozwy wobec użytkowników nakładek

Organizacje korzystające z produktów typu nakładka wciąż stają w obliczu pozwów na podstawie ADA Title III. Nakładka nie zadziałała jako prawna ochrona.

Do godnych uwagi przypadków należą:

Lainey Feingold i NFB — National Federation of the Blind jednoznacznie stwierdziła, że widżety nakładek nie stanowią efektywnej dostępności i że NFB nie uważa ich za rozsądny substytut prawdziwej naprawy.

Liczne pozwy w sądach federalnych — powodowie w sprawach o dostępność witryn na podstawie ADA skutecznie argumentowali, że obecność nakładki nie stanowi zgodności, ponieważ leżąca pod nią strona wciąż stawia bariery użytkownikom konkretnych technologii wspomagających. Sądy się z tym zgodziły. W kilku ugodach pozwani korzystający z produktów typu nakładka zostali zobowiązani do usunięcia nakładki i podjęcia prawdziwej naprawy.

Robles v. Domino’s Pizza — choć nie jest to sprawa dotycząca konkretnie nakładek, to przełomowe orzeczenie Dziewiątego Okręgu ustanowiło, że ADA obejmuje witryny internetowe i że oczekiwanym standardem technicznym jest WCAG. Sądy oceniające efektywność nakładek stosowały ten standard: czy strona faktycznie spełnia WCAG? Nakładka jest nieistotna, jeśli leżąca pod nią strona tego nie robi.

Problem nakładki jako dowodu

W niektórych przypadkach obecność nakładki została wykorzystana przeciwko pozwanym. Argument: kupując i instalując nakładkę, organizacja potwierdziła, że strona miała problemy z dostępnością. Niepowodzenie nakładki w rozwiązaniu tych problemów zatem świadczy o dalszym, świadomym braku zgodności — trudniejszej pozycji niż w przypadku organizacji, która po prostu jeszcze nie zajęła się dostępnością.

Ugody z DOJ i decyzje ugodowe

Ugody Departamentu Sprawiedliwości (DOJ) w sprawach dostępności konsekwentnie wymagają rzeczywistej zgodności z WCAG, nie instalacji narzędzi zgodności. Żadna z opublikowanych ugód DOJ lub dobrowolnych porozumień o zgodności nie uznała produktów typu nakładka za spełniające obowiązki wynikające z ADA.

Co obiecują dostawcy nakładek, a co faktycznie dostarczają

Dostawcy nakładek składają konkretne obietnice, które warto zbadać indywidualnie:

„Natychmiastowa zgodność z WCAG 2.1”

Zgodność z WCAG 2.1 jest właściwością samej strony, nie warstwy nałożonej na nią. Strona, która nie przechodzi testu dostępności klawiaturowej, ma brakujący tekst alternatywny lub nie ma poprawnej struktury nagłówków, nie staje się zgodna z WCAG, ponieważ zainstalowano widżet. Model zgodności W3C wymaga, aby strona spełniała każde kryterium sukcesu — nie tego, by narzędzie twierdziło, że tak jest.

„Zgodność prawna”

Zgodność prawna na podstawie ADA, PSBAR, EAA lub równoważnych ram zależy od tego, czy strona faktycznie stawia bariery użytkownikom z niepełnosprawnościami. Sądy i regulatorzy oceniają to, testując stronę tak, jak doświadczają jej użytkownicy — często z udziałem rzeczywistych użytkowników technologii wspomagającej. Nakładka, która nie usuwa wiarygodnie barier, nie zapewnia ochrony prawnej.

„Działa z czytnikami ekranu”

Czytniki ekranu wchodzą w interakcję z drzewem dostępności wywodzącym się z DOM. Nakładka nakładająca modyfikacje JavaScript po wyrenderowaniu może nie zostać odzwierciedlona w drzewie dostępności, które odczytuje czytnik ekranu. To nie jest teoretyczny przypadek skrajny — jest to powszechny sposób awarii dokumentowany w testach z użytkownikami.

„Używane przez [duża liczba] witryn”

Penetracja rynku nie nadaje wartości prawnej. Badania WebAIM wskazują, że skala korelowała z gorszymi wynikami dostępności, nie lepszymi.

„Uwolnij się od pozwów o WCAG”

Żaden dostawca nakładki nie może prawnie zagwarantować uwolnienia od pozwów. Zgodność z WCAG, którą sądy faktycznie oceniają, to zgodność leżącej pod nią strony — czegoś, czego nakładka nie może stworzyć.

Dlaczego organizacje mimo to kupują nakładki

Zrozumienie, dlaczego nakładki znalazły rynek, pomaga wyjaśnić, czemu ich przekaz jest tak skuteczny, nawet gdy produkt nie jest.

Koszt i szybkość. Prawdziwy program naprawy dostępności — audyt, naprawa, ponowny test, szkolenie, monitorowanie — zajmuje czas i pieniądze. Nakładka kosztuje kilkaset dolarów rocznie i instaluje się w kilka minut. Dla organizacji stojących przed wynikami audytu lub presją prawną w krótkim terminie, kontrast jest wyrazisty.

Wiarygodne alibi. Niektóre organizacje kupują nakładki nie dlatego, że wierzą, że działają, ale by stworzyć ślad dokumentacyjny. „Kupiliśmy rozwiązanie dostępności” to lepsza pozycja niż „nic nie zrobiliśmy” — nawet jeśli sądy w dużej mierze odrzuciły ten argument.

Taktyki sprzedażowe dostawców. Dostawcy nakładek intensywnie inwestują w sprzedaż agencjom internetowym, zespołom zakupowym i specjalistom od zgodności, którzy mogą nie mieć głębokiej wiedzy z zakresu dostępności. Twierdzenia o „zgodności z ADA” i „certyfikacji WCAG” są składane z pewnością i trudno je szybko zweryfikować osobom niebędącym specjalistami.

Niezrozumienie problemu. Dostępność cyfrowa jest techniczna, a wielu decydentów nie w pełni rozumie, czemu naprawa leżącego pod nią kodu jest konieczna. Przedstawianie nakładek jako „narzędzia” lub „rozwiązania” sugeruje równoważność z prawdziwą naprawą.

Co zrobić zamiast tego

Jeśli Twoja organizacja obecnie korzysta z nakładki i rozważa, czy kontynuować, ramowy plan jest prosty:

Zaudytuj swoją witrynę niezależnie. Zamów audyt dostępności, który testuje leżącą pod nią stronę — nie wersję zmodyfikowaną przez nakładkę. To daje Ci uczciwy obraz rzeczywistej zgodności. Wielu audytorów wyłącza nakładkę przed testowaniem.

Priorytetyzuj swoje najczęściej używane przepływy. Bariery najwyższego ryzyka to te w kluczowych ścieżkach użytkownika: logowanie, zakup, zarządzanie kontem, formularze aplikacji, główna nawigacja. To one są testowane przez powodów i badane przez regulatorów. Napraw je najpierw.

Napraw leżący pod nią kod. Praca dotyczy HTML, CSS, JavaScriptu i treści — nie warstwy nałożonej na nie. Wymaga to czasu programistów oraz, najlepiej, wiedzy z zakresu dostępności wbudowanej w zespół lub zaangażowanej z zewnątrz.

Wbuduj monitorowanie w swój przepływ pracy. Automatyczne kontrole dostępności w potoku rozwoju wychwytują regresje, zanim dotrą do użytkowników. Nasza integracja dostępności w CI/CD sprawia, że to część każdego builda.

Przeszkol swój zespół. Deweloperzy rozumiejący WCAG piszą dostępny kod. Projektanci rozumiejący dostępność projektują dostępne interfejsy. Jednodniowe szkolenie z dostępności wielokrotnie zwraca się w unikniętych kosztach naprawy.

Opublikuj uczciwą deklarację dostępności. Deklaracja dostępności, która precyzyjnie opisuje znane problemy i plany naprawy, demonstruje dobrą wiarę wobec regulatorów i użytkowników. Daje też użytkownikom bezpośredni kanał do zgłaszania barier, zanim się eskalują.

Miejsce nakładki w prawdziwym programie dostępności

To nie jest argument, że technologia nakładek nie ma żadnego miejsca w żadnym programie dostępności. Niektóre funkcje nakładek — preferencje kontrastu kontrolowane przez użytkownika, regulacja rozmiaru czcionki, ograniczenie ruchu — mogą być naprawdę użytecznymi ulepszeniami w dodatku do dostępnej, leżącej pod nimi witryny.

Problemem jest używanie nakładki zamiast dostępności. Taka podmiana nie działa technicznie, nie spełnia standardów prawnych i zawodzi użytkowników, którym nakładka twierdzi, że pomaga.

Prawdziwa dostępność nie jest widżetem. Jest właściwością kodu, treści i projektu samej strony — wbudowaną, nie doczepioną.

Jeśli Twoja organizacja obecnie polega na nakładce w kwestii zgodności, bezpłatne skanowanie dostępności pokaże Ci bariery, które istnieją pod nią. Nasz zespół doradztwa w zakresie dostępności może pomóc Ci zbudować realistyczny plan naprawy, który zajmuje się leżącymi pod nią problemami, a nie je tuszuje.