Na wielu stronach internetowych pojawia się charakterystyczny przycisk z symbolem osoby, oka albo dłoni. Po jego uruchomieniu użytkownik może zwiększyć tekst, zmienić kontrast, podkreślić linki, zatrzymać animacje albo włączyć uproszczony widok.
Takie rozwiązania są często przedstawiane jako szybki sposób na zapewnienie dostępności cyfrowej. Dostawca instaluje dodatkowy skrypt, w panelu pojawia się kilka funkcji, a właściciel strony otrzymuje komunikat, że serwis został dostosowany do potrzeb osób z niepełnosprawnościami.
Problem polega na tym, że nakładka nie zmienia podstawowej jakości strony. Nie poprawia automatycznie błędnej struktury dokumentu, niedostępnego formularza, niewłaściwej obsługi klawiaturą ani źle zaprojektowanego procesu zakupowego. Może zmienić sposób prezentacji niektórych elementów, ale nie zastępuje poprawnego projektu, kodu, treści i testów.
WCAG określa dostępność na podstawie wymagań dotyczących samej treści i sposobu jej działania. Zgodność powinna być oceniana z użyciem testów automatycznych i oceny człowieka, a nie na podstawie obecności dodatkowego przycisku w interfejsie.
Widżet dostępności nie jest tym samym co dostępna strona
Panel umożliwiający zmianę kontrastu lub wielkości tekstu może być użytecznym dodatkiem. Nie oznacza to jednak, że strona spełnia wymagania dostępności.
Jeżeli menu nie działa bez myszy, widżet nie przebuduje jego logiki. Jeżeli pola formularza nie mają poprawnych etykiet, zwiększenie czcionki nie wyjaśni użytkownikowi, jakie dane należy wpisać. Jeżeli komunikat o błędzie nie jest przekazywany czytnikowi ekranu, zmiana kolorystyki nie pozwoli go odnaleźć.
Nakładka działa zwykle na końcu procesu, po załadowaniu istniejącej strony. Próbuje modyfikować treść lub zachowanie elementów, których wcześniej nie zaprojektowano prawidłowo.
Może pomóc w wybranych sytuacjach, lecz nie usuwa przyczyny problemu. To różnica podobna do zmiany sposobu wyświetlania dokumentu bez poprawienia jego struktury.
Dostępność powinna być wbudowana w serwis od początku. Dodatkowe narzędzia mogą ją wspierać, ale nie powinny być traktowane jako zamiennik prawidłowej realizacji.
Zwiększenie tekstu nie naprawia błędnego powiększenia strony
Jedną z najczęstszych funkcji widżetu jest możliwość zwiększenia rozmiaru tekstu. Funkcja ta wygląda atrakcyjnie podczas prezentacji, ponieważ efekt jest widoczny natychmiast.
Użytkownicy mogą jednak powiększać treść za pomocą przeglądarki, systemu operacyjnego i własnych technologii wspomagających. Strona powinna działać poprawnie przy takim powiększeniu bez konieczności uruchamiania dodatkowego panelu.
Jeżeli po powiększeniu tekst nachodzi na inne elementy, znika poza ekranem albo wymaga przewijania w dwóch kierunkach, problem znajduje się w układzie strony. Wbudowany przycisk może zwiększać wyłącznie wybrane fragmenty i omijać menu, formularze lub elementy zewnętrzne.
Może też stosować własne style, które działają tylko w określonej wersji serwisu. Po aktualizacji motywu albo dodaniu nowego komponentu część treści przestaje reagować na ustawienia widżetu.
Rzetelny audyt sprawdza zachowanie serwisu przy standardowych metodach powiększania. Nie ogranicza się do oceny funkcji przygotowanej przez właściciela strony.
Tryb wysokiego kontrastu nie poprawi każdej nieczytelnej informacji
Zmiana kolorów może ułatwić korzystanie ze strony części użytkowników. Nie rozwiązuje jednak automatycznie wszystkich problemów z kontrastem.
Widżet może poprawić wygląd tekstu, ale pominąć ikony, obramowania pól, wykresy, grafiki, stany aktywne i komunikaty błędów. Może także zmienić kolory w taki sposób, że poszczególne elementy przestają się od siebie odróżniać.
Problemem są również informacje przekazywane wyłącznie kolorem. Jeżeli czerwone pole oznacza błąd, a zielone poprawność, samo zwiększenie kontrastu nie dodaje brakującego komunikatu tekstowego.
Użytkownicy słabowidzący mogą korzystać z własnych ustawień kolorystycznych. Dodatkowa nakładka może nadpisywać te preferencje albo powodować konflikt z trybem wysokiego kontrastu systemu.
Poprawny serwis powinien być czytelny i zrozumiały bez wymuszania jednego specjalnego trybu przeznaczonego dla osób z niepełnosprawnościami.
Nakładka nie stworzy prawidłowej struktury treści
Czytnik ekranu nie odbiera strony tak jak osoba patrząca na jej wygląd. Korzysta z informacji zapisanych w kodzie: nagłówków, list, tabel, etykiet, nazw przycisków i relacji między elementami.
Strona może wyglądać jak uporządkowany dokument, ale w kodzie wszystkie śródtytuły mogą być zwykłymi akapitami. Tabela może nie posiadać wskazanych nagłówków, a przycisk może być odczytywany jako nieznany element.
Nakładka musiałaby prawidłowo rozpoznać znaczenie każdego fragmentu i odtworzyć intencję autora. W wielu przypadkach nie ma wystarczających informacji, aby zrobić to wiarygodnie.
Duży, pogrubiony tekst nie zawsze jest nagłówkiem. Może być cytatem, nazwą produktu, ostrzeżeniem albo elementem dekoracyjnym. Automatyczne przypisanie mu roli nagłówka może stworzyć fałszywą strukturę.
Podobnie jest z obrazami. System może próbować generować ich opisy na podstawie rozpoznawania zawartości, ale nie zna celu publikacji. Nie wie, czy fotografia jest dekoracyjna, przedstawia ważny wykres, potwierdza stan faktyczny czy stanowi przycisk prowadzący do kolejnego etapu.
Automatyczna ingerencja może więc dodawać informacje niepełne, niepotrzebne albo błędne.
Obsługi klawiaturą nie da się wiarygodnie naprawić jednym skryptem
Dostępność klawiaturowa wymaga, aby użytkownik mógł dotrzeć do wszystkich funkcji, rozpoznać aktualnie aktywny element i wykonać potrzebne działania bez użycia myszy.
Problemy dotyczą nie tylko możliwości naciśnięcia przycisku. Liczy się kolejność przechodzenia, widoczność fokusu, zachowanie menu, okien dialogowych, kalendarzy, rozwijanych list i innych komponentów.
Nakładka może próbować dodawać atrybuty albo reagować na naciśnięcie klawiszy. Nie zna jednak pełnej logiki aplikacji. Może wprowadzić fokus do elementu, którego nie da się później zamknąć, albo zmienić kolejność w sposób sprzeczny z układem treści.
Szczególnie trudne są elementy dynamiczne. Po otwarciu okna fokus powinien zostać przeniesiony w odpowiednie miejsce, pozostać wewnątrz okna podczas interakcji, a po zamknięciu wrócić do elementu, który je uruchomił.
Takiego zachowania nie można bezpiecznie uogólnić dla każdej strony i każdego komponentu za pomocą jednego zewnętrznego rozwiązania.
Widżet może sam stać się barierą
Panel dostępności jest dodatkowym elementem interfejsu. On również musi być prawidłowo zaprojektowany, opisany i możliwy do obsłużenia.
Może zasłaniać treść, przycisk kontaktowy lub komunikat o cookies. Na małym ekranie może zajmować znaczną część przestrzeni. Jeżeli rozwija się automatycznie albo reaguje na najechanie kursorem, może utrudniać korzystanie osobom z ograniczoną precyzją ruchu.
Treści pojawiające się po najechaniu lub ustawieniu fokusu mogą powodować problemy, gdy użytkownik nie potrafi ich zamknąć, utrzymać na ekranie albo kontynuować pracy bez ich zasłaniania. WCAG wskazuje na takie ryzyka przy dodatkowej treści wyświetlanej po najechaniu lub fokusie.
Zdarza się również, że przycisk widżetu pojawia się jako pierwszy element w kolejności klawiaturowej na każdej podstronie. Osoba korzystająca z klawiatury musi przechodzić przez panel wielokrotnie, mimo że w ogóle go nie potrzebuje.
Narzędzie promowane jako rozwiązanie dostępności może więc tworzyć kolejną przeszkodę.
Technologia wspomagająca użytkownika nie potrzebuje symulacji
Część nakładek oferuje funkcję określaną jako „czytnik strony” lub „tryb czytnika ekranu”. Może ona odczytywać tekst po wskazaniu kursorem albo zmieniać sposób prezentacji serwisu.
Nie jest to odpowiednik technologii wspomagającej używanej przez osoby niewidome. Czytniki ekranu współpracują z systemem operacyjnym, przeglądarką i aplikacjami. Pozwalają poruszać się po nagłówkach, formularzach, tabelach, regionach i kontrolkach.
Wbudowany lektor strony zwykle odczytuje jedynie wybrane teksty. Nie zastępuje pełnej nawigacji ani dostępu do wszystkich funkcji.
Może też wprowadzać błędne przekonanie, że strona jest dostępna, ponieważ „potrafi mówić”. Tymczasem osoba korzystająca z własnego czytnika nadal napotyka problemy w kodzie i strukturze.
Dostępny serwis powinien współpracować z technologiami użytkownika. Nie powinien wymuszać korzystania z osobnego, ograniczonego rozwiązania dostarczonego przez właściciela strony.
Automatyczne poprawki mogą być niestabilne
Nakładki często analizują stronę i modyfikują ją podczas ładowania. Skuteczność takiego działania zależy od struktury kodu, kolejności uruchamiania skryptów i późniejszych zmian w serwisie.
Aktualizacja motywu, wtyczki lub komponentu może sprawić, że reguła przestanie działać. Element otrzyma inną klasę, zostanie załadowany później albo pojawi się dopiero po wykonaniu określonej czynności.
Właściciel strony może nie wiedzieć, że automatyczna poprawka przestała obejmować część serwisu. Widżet nadal jest widoczny, abonament jest opłacany, a użytkownik napotyka tę samą barierę.
Zależność od zewnętrznego skryptu tworzy również dodatkowe ryzyko techniczne. Awaria dostawcy, konflikt JavaScript lub blokowanie zasobu przez przeglądarkę może spowodować, że funkcje przestaną działać.
Dostępność nie powinna zależeć wyłącznie od warstwy, której właściciel serwisu nie kontroluje i nie potrafi samodzielnie zweryfikować.
Nakładka nie naprawi plików i systemów zewnętrznych
Strona może zawierać dokumenty PDF, formularze osadzone w ramkach, mapy, filmy, płatności i systemy rezerwacji. Widżet działający w głównym serwisie często nie ma dostępu do ich struktury.
Nie poprawi skanu regulaminu, nie doda napisów do nagrania i nie zmieni niedostępnego panelu operatora płatności. Nie naprawi aplikacji otwieranej pod inną domeną ani dokumentu pobieranego na urządzenie.
Użytkownik nadal zatrzyma się na etapie koniecznym do wykonania zadania.
Dlatego ocena dostępności musi obejmować cały proces i wszystkie jego elementy. Obecność nakładki na stronie głównej nie ma znaczenia, jeżeli właściwa usługa jest realizowana w niedostępnym systemie.
Certyfikat dostawcy nakładki nie zastępuje audytu
Dostawca może przekazać raport, certyfikat albo oświadczenie, że po instalacji strona spełnia określony standard.
Trzeba jednak sprawdzić, czego dokładnie dotyczy dokument. Może opisywać możliwości samego narzędzia, a nie rzeczywisty stan konkretnego serwisu. Może również opierać się na badaniu automatycznym lub analizie ograniczonej liczby podstron.
W3C wskazuje, że ocena zgodności z WCAG wymaga określenia zakresu serwisu, reprezentatywnej próbki, badania kryteriów i udokumentowania wyników. Metodologia WCAG-EM służy właśnie uporządkowanej ocenie tego, jak cały serwis spełnia wymagania.
Nie można więc potwierdzić dostępności wyłącznie na podstawie instalacji produktu. Trzeba zbadać konkretną stronę, jej treści, komponenty i procesy.
Wysoki wynik automatyczny może wynikać z ukrywania problemów
Niektóre rozwiązania modyfikują kod w taki sposób, aby automatyczny skaner przestał zgłaszać określony błąd. Nie zawsze oznacza to, że poprawiła się sytuacja użytkownika.
Element może otrzymać automatycznie wygenerowaną nazwę, która formalnie istnieje, ale jest niezrozumiała. Obraz może dostać przypadkowy opis. Kontrolka może zostać ukryta przed czytnikiem ekranu zamiast naprawiona.
Raport pokaże mniej błędów, ponieważ narzędzie rozpoznaje obecność wymaganego atrybutu. Człowiek nadal nie będzie w stanie poprawnie wykonać zadania.
W3C podkreśla, że narzędzia wspierają ocenę dostępności, lecz żadne pojedyncze narzędzie nie potrafi samodzielnie ustalić pełnej zgodności serwisu.
Liczba błędów w raporcie nie może więc być jedynym wskaźnikiem jakości.
Widżet może utrudniać korzystanie z osobistych ustawień
Osoby z niepełnosprawnościami często mają już skonfigurowane własne środowisko. Korzystają z określonego powiększenia, kolorów, czcionek, skrótów klawiaturowych i technologii wspomagających.
Nakładka może nadpisywać te preferencje. Zamiast dopasować stronę do użytkownika, wymusza własny zestaw opcji.
Może też zapisywać ustawienia w plikach cookies albo przywracać je przy kolejnej wizycie bez jasnej informacji. Po zmianie urządzenia lub przeglądarki użytkownik musi ponownie konfigurować sposób wyświetlania.
Dostępny projekt powinien respektować ustawienia systemowe i przeglądarkowe. Nie powinien zakładać, że każdy użytkownik potrzebuje tego samego specjalnego panelu.
Nakładka może odwracać uwagę od rzeczywistych napraw
Największym zagrożeniem nie zawsze jest samo narzędzie. Problemem bywa przekonanie organizacji, że po jego instalacji temat dostępności został zamknięty.
Budżet na poprawki zostaje przeznaczony na abonament, a błędy w kodzie i treści pozostają nierozwiązane. Redaktorzy nie otrzymują szkolenia, wykonawca nie poprawia komponentów, a nowe materiały są publikowane bez kontroli.
Widżet staje się widocznym symbolem dostępności, ale nie zmienia codziennego procesu.
Taka sytuacja utrudnia również reagowanie na zgłoszenia. Instytucja może odpowiadać użytkownikowi, że powinien uruchomić panel, mimo że jego problem dotyczy formularza, dokumentu albo systemu zewnętrznego.
Dostępność nie powinna wymagać od osoby z niepełnosprawnością samodzielnego uruchamiania mechanizmu naprawiającego stronę.
Nie każdy dodatkowy panel jest bezużyteczny
Krytyka nakładek nie oznacza, że każda funkcja personalizacji jest błędna.
Możliwość zatrzymania animacji, zmiany sposobu prezentacji albo przełączenia na prostszy język może być wartościowa, szczególnie gdy wynika ze specyfiki serwisu i została dobrze przetestowana.
Warunkiem jest jednak traktowanie jej jako dodatkowej funkcji, a nie dowodu spełnienia WCAG. Podstawowa wersja strony nadal powinna być poprawna, dostępna i współpracować z technologiami wspomagającymi.
Warto również ocenić, czy dana opcja odpowiada na rzeczywistą potrzebę użytkowników. Panel zawierający kilkanaście efektownych przełączników może być mniej użyteczny niż jedna dobrze zaprojektowana funkcja obecna w odpowiednim miejscu.
Audyt powinien sprawdzać stronę także po wyłączeniu nakładki
Jeżeli serwis korzysta z widżetu, audyt powinien rozdzielić dwa zagadnienia. Pierwszym jest dostępność podstawowej strony, drugim działanie samego dodatku.
Trzeba ustalić, które bariery istnieją w kodzie źródłowym, które są jedynie częściowo maskowane oraz czy panel nie tworzy nowych problemów.
Badanie powinno obejmować różne stany: przed uruchomieniem widżetu, po zmianie ustawień, po przejściu na kolejną podstronę oraz przy współpracy z technologiami wspomagającymi.
Tylko taka ocena pozwala stwierdzić, czy narzędzie rzeczywiście pomaga, czy jedynie zmienia wygląd strony.
Dostępności nie instaluje się jednym przyciskiem
Dostępna strona wymaga poprawnej struktury, działania klawiaturą, czytelnych formularzy, zrozumiałych treści, dostępnych dokumentów i kontroli pełnych procesów.
Nakładka może dodać wybrane opcje personalizacji, ale nie zastąpi tej pracy. Nie zna celu każdej treści, nie rozumie relacji organizacyjnych i nie przewidzi wszystkich sposobów korzystania z serwisu.
Obietnica automatycznego naprawienia całej strony jest atrakcyjna, ponieważ pozwala uniknąć zmian w kodzie, treści i procedurach. W praktyce najczęściej prowadzi do pozornego rozwiązania.
Prawdziwa dostępność powstaje wtedy, gdy bariery są usuwane u źródła. Formularz otrzymuje właściwe etykiety, komponent działa z klawiaturą, dokument zostaje poprawnie przygotowany, a proces jest testowany przez człowieka.
Widżet może być dodatkiem. Nie powinien być strategią dostępności, substytutem audytu ani podstawą deklarowania zgodności.