Dostępność ≠ Overlay: gdy overlay zakłóca działanie czytnika ekranu
Czytniki ekranu przekazują mową lub brajlem informacje, które interfejs udostępnia programowo. Użytkownicy poznają ich polecenia, konfigurują ustawienia i wypracowują strategie poruszania się po nagłówkach, linkach, regionach, formularzach i kontrolkach. W3C zalicza czytniki ekranu do technologii wspomagających używanych w sieci. Punktem wyjścia powinna więc być poprawnie zbudowana strona, a nie próba zastąpienia technologii użytkownika przez samą witrynę.
Czytnik ekranu jest już technologią wspomagającą użytkownika
Czytniki ekranu przekazują mową lub brajlem informacje, które interfejs udostępnia programowo. Użytkownicy poznają ich polecenia, konfigurują ustawienia i wypracowują strategie poruszania się po nagłówkach, linkach, regionach, formularzach i kontrolkach. W3C zalicza czytniki ekranu do technologii wspomagających używanych w sieci. Punktem wyjścia powinna więc być poprawnie zbudowana strona, a nie próba zastąpienia technologii użytkownika przez samą witrynę.
Czego czytnik ekranu naprawdę potrzebuje od strony
Interoperacyjność zależy od kodu: semantycznego HTML, prawdziwych nagłówków, rozpoznawalnych linków i przycisków, etykiet powiązanych z polami, poprawnych nazw dostępnościowych, ról, stanów i wartości oraz spójnego zarządzania fokusem. W3C wyjaśnia, że czytniki ekranu mogą używać struktury nagłówków do nawigacji, a standardowe kontrolki HTML wspierają współpracę z technologiami wspomagającymi. Jeśli ta podstawa zawodzi, problem leży w implementacji strony.
Co zmienia overlay
Niektóre overlaye wstrzykują zewnętrzny JavaScript, który analizuje stronę i próbuje naprawiać problemy front-endu. Technologia wspomagająca może więc otrzymać zmodyfikowaną wersję interfejsu. Overlay Fact Sheet ostrzega, że takie naprawy mogą spowalniać ładowanie lub powodować nieoczekiwane zmiany dla użytkowników technologii wspomagających. Nie oznacza to, że każdy overlay zawsze powoduje ten sam błąd, ale dodaje kolejną zmienną między stroną a czytnikiem.
Fokus, klawiatura i struktura: małe zmiany mogą stać się dużymi barierami
Dla osoby nawigującej bez wzroku fokus określa, gdzie się znajduje i jaki element będzie obsługiwać. Nieoczekiwane skoki fokusu, przechwycone klawisze lub zmieniona semantyka mogą całkowicie dezorientować. Podobnie sztuczne nagłówki, niewiarygodne nazwy czy źle ogłaszane stany. Overlay Fact Sheet zbiera doświadczenia użytkowników opisujących skoki fokusu i utrudnioną nawigację po włączeniu overlayu.
Przycisk „profil czytnika ekranu” stawia niewłaściwe pytanie
Pytanie nie powinno brzmieć, czy użytkownik włączył specjalny profil, lecz czy strona od początku działa z jego zwykłą technologią wspomagającą. W3C wskazuje, że ludzie używają różnych konfiguracji i narzędzi zgodnie z potrzebami i preferencjami. Konieczność znalezienia widżetu, otwarcia go i wybrania dodatkowego trybu dodaje kroki bez gwarancji usunięcia pierwotnych barier.
Nie wszyscy użytkownicy czytników ekranu nawigują tak samo
NVDA, JAWS, VoiceOver, TalkBack i inne rozwiązania mają różne polecenia i tryby. Użytkownicy indywidualnie ustawiają też mowę, szybkość, interpunkcję, brajl i sposób nawigacji. Projektowanie jednej uniwersalnej „obsługi czytnika ekranu” jest ryzykowne. Solidna dostępność udostępnia standardowe i przewidywalne informacje.
Poprawna semantyka pozwala użytkownikowi decydować o sposobie nawigacji
Dobry nagłówek to nie tylko duży tekst. Pole nie staje się dostępne tylko dlatego, że obok wizualnie znajduje się słowo. Odpowiedni HTML i, gdy potrzeba, poprawne ARIA pozwalają czytnikowi przekazać strukturę, a użytkownikowi nawigować własnymi poleceniami. W3C zaleca elementy natywne, gdy jest to możliwe, a ARIA służy do przekazywania ról, stanów i właściwości.
Testowanie czytnikiem ekranu to nie tylko sprawdzenie, czy strona mówi
Samo słyszenie tekstu nie dowodzi użyteczności strony. Trzeba sprawdzać pełne zadania: dotarcie do głównej treści, zrozumienie hierarchii, obsługę menu i formularzy, rozpoznawanie błędów, dialogi i komponenty dynamiczne oraz odzyskanie orientacji po interakcji. Ważne są też testy klawiaturą i z osobami regularnie używającymi tych technologii.
Co firma powinna zrobić zamiast polegać na warstwie
Najpierw należy zidentyfikować rzeczywiste bariery, a potem poprawić je w komponencie, szablonie, motywie lub aplikacji, która je tworzy. Potrzebne są semantyczny HTML, dostępne wzorce, poprawne zarządzanie fokusem i testy z reprezentatywnymi kombinacjami przeglądarek i technologii wspomagających. Automatyzacja może wykrywać część problemów, ale nie zastępuje testów funkcjonalnych i ludzkich.
Dostępność ≠ Overlay
Entrega 06 opiera się na prostej idei: czytnik ekranu należy do użytkownika, nie do strony. Witryna powinna zapewniać stabilny, przewidywalny interfejs, z którym ta technologia może współpracować. Jeśli dodatkowa warstwa zmienia strukturę, fokus lub semantykę, znana bariera może zmienić się w inną, trudniejszą do zdiagnozowania. Trwałym rozwiązaniem pozostaje poprawa u źródła i testy z rzeczywistymi technologiami wspomagającymi.
Oficjalne i techniczne źródła
W3C Web Accessibility Initiative (WAI)
Tools and Techniques — How People with Disabilities Use the Web
Page Structure Tutorial
WAI-ARIA Overview
Overlay Fact Sheet
Overlay Fact Sheet — assistive technology experiences and limitations
Entrega 06 — Overlays y lectores de pantalla.