Testy czytników: NVDA, JAWS, VoiceOver

Strona może przejść każdą zautomatyzowaną kontrolę, zostać wdrożona z poprawnym HTML i mimo to być nieużyteczna dla kogoś, kto porusza się po sieci słuchem. Narzędzia automatyczne wychwytują mniej więcej jedną trzecią problemów z dostępnością; reszta tkwi w przepaści między tym, co drzewo dostępności technicznie zawiera, a tym, co czytnik ekranu faktycznie obwieszcza użytkownikowi. Zniwelowanie tej przepaści oznacza postawienie interfejsu przed tymi samymi narzędziami, na których polega Twoja publiczność — i właśnie do tego służy testowanie czytników ekranu.

Ten przewodnik omawia, czym różnią się główne czytniki ekranu, dlaczego testowanie tylko jednego z nich nigdy nie wystarcza, co dokładnie testować, jakich kombinacji czytnika i przeglądarki używać oraz jakie pułapki łapią nawet doświadczone zespoły. Jest napisany dla deweloperów, inżynierów QA i specjalistów ds. dostępności, którzy chcą testować świadomie, a nie zgadywać. Jeśli wolisz powierzyć tę pracę specjalistom korzystającym z tych narzędzi na co dzień, nasza usługa oceny z czytnikami ekranu robi dokładnie to.

Dlaczego czytnik ekranu nie jest narzędziem do „czytania na głos”

Najczęstszym błędnym przekonaniem jest, że czytnik ekranu po prostu wypowiada tekst na stronie. Robi on znacznie więcej, a zrozumienie tej różnicy jest fundamentem dobrego testowania. Czytnik ekranu buduje równoległy, niewizualny model interfejsu na podstawie drzewa dostępności przeglądarki. Obwieszcza nazwę każdego elementu („Wyślij, przycisk”), jego rolę (przycisk, łącze, nagłówek, pole wyboru) oraz jego stan (zaznaczone, rozwinięte, wyłączone, wymagane). Pozwala użytkownikowi przeskakiwać między nagłówkami, punktami orientacyjnymi, polami formularza i łączami bez dotykania układu wizualnego. Wypowiada zmiany dynamiczne — komunikaty o błędach, wyniki wyszukiwania, aktualizacje stanu — gdy zmiany te są poprawnie udostępnione.

To zasadniczo różni się od syntezy mowy, która zamienia blok tekstu w dźwięk bez żadnego pojęcia o rolach, stanach czy nawigacji. Omawiamy to rozróżnienie szczegółowo w synteza mowy a czytniki ekranu, a ma ono tu znaczenie, ponieważ testowanie pod kątem jednego nie jest testowaniem pod kątem drugiego. Użytkownik czytnika ekranu nie konsumuje Twojej strony od góry do dołu; porusza się po niej strukturalnie i oczekuje, że każdy element interaktywny zadeklaruje, czym jest i co robi.

Czym różnią się NVDA, JAWS, VoiceOver i TalkBack

Cztery czytniki, o które większość zespołów musi dbać, zachowują się na tyle różnie, że „działa w jednym” nie mówi prawie nic o pozostałych.

NVDA (Windows)

NVDA to darmowy czytnik o otwartym kodzie źródłowym i najczęściej używany czytnik ekranu na świecie. Najnaturalniej współpracuje z Firefoksem i Chrome. NVDA zazwyczaj ściśle podąża za semantyką ARIA i HTML, co czyni go doskonałym punktem odniesienia: jeśli coś w Twoim znaczniku jest zepsute, NVDA często ujawnia to wprost. Ma dwa kluczowe tryby — tryb przeglądania (do czytania i nawigacji strukturalnej) oraz tryb formularzy (do wpisywania w formularzach i obsługi widżetów) — a częstym źródłem błędów są widżety, które nie wyzwalają poprawnego przełączenia trybu.

JAWS (Windows)

JAWS to ugruntowany od dawna komercyjny czytnik, wciąż dominujący w przedsiębiorstwach, administracji i wielu miejscach pracy. Współpracuje z Chrome i Edge. JAWS słynie z bycia „pomocnym”: stosuje heurystyki, które zgadują znaczenie, czasem obwieszcza rzeczy, o których NVDA milczy, i okazjonalnie wygładza błędy znaczników, które powinny zostać naprawione. Ta pomocność działa w obie strony — kod, który „działa w JAWS”, może zawieść w NVDA lub VoiceOver, ponieważ JAWS zatuszował problem. Ma też własny wirtualny kursor i zachowanie trybu formularzy, które subtelnie różni się od tego w NVDA.

VoiceOver (macOS i iOS)

VoiceOver jest wbudowany w każdego Maca, iPhone’a i iPada i współpracuje niemal wyłącznie z Safari. Na macOS nawigacja odbywa się za pomocą pokrętła i kombinacji z klawiszem VO; na iOS jest w całości oparta na gestach — przesunięcie, by się przemieścić, podwójne stuknięcie, by aktywować, pokrętło przez obrócenie dwoma palcami. VoiceOver jest na ogół najbardziej rygorystyczny z całej czwórki wobec ARIA: często milczy zamiast zgadywać, gdy brakuje nazw lub ról, więc kontrolka, którą JAWS obwieszcza, w VoiceOver może nie powiedzieć nic. VoiceOver na komputerze i w wersji mobilnej także różnią się od siebie, więc liczą się jako dwa odrębne cele testowe.

TalkBack (Android)

TalkBack to wbudowany czytnik Androida, sparowany z Chrome. Podobnie jak VoiceOver na iOS jest oparty na gestach, ale jego gesty, zachowanie fokusu oraz obsługa obszarów aktywnych i niestandardowych kontrolek różnią się od tych w VoiceOver. Czytniki mobilne ogólnie ujawniają problemy, które nigdy nie pojawiają się na komputerze: cele dotykowe nieosiągalne przez przesunięcie, fokus przeskakujący nieoczekiwanie po przejściu między ekranami oraz treści obecne wizualnie, lecz całkowicie pomijane przez liniową kolejność gestów.

Dlaczego testowanie wielu czytników jest niezbędne

Ponieważ czytniki te rozchodzą się w sposobie interpretacji dokładnie tego samego znacznika, testowanie jednym czytnikiem daje fałszywe poczucie bezpieczeństwa. Kilka konkretnych wzorców pojawia się raz za razem:

• Niestandardowy combobox, który JAWS obwieszcza bezbłędnie, może całkowicie zamilknąć w VoiceOver, ponieważ VoiceOver odmawia wywnioskowania brakującej role lub stanu aria-expanded.
• Obszar aktywny, który NVDA obwieszcza grzecznie raz, może być obwieszczany wielokrotnie lub wcale w innym czytniku, w zależności od tego, jak aria-live i moment wstawienia do DOM współdziałają ze sobą.
• Kontrolka z nadmiarową lub sprzeczną nazwą (widoczna etykieta plus aria-label plus title) może być sensownie obwieszczona przez jeden czytnik, a przez inny jako mylący ciąg duplikatów.
• Kolejność czytania, która odpowiada kolejności wizualnej w jednej parze przeglądarka/czytnik, może rozejść się w innej, gdy CSS zmienia kolejność treści, a DOM nie.

Każdy czytnik jest też powiązany z inną przeglądarką, więc tak naprawdę testujesz kombinacje czytnik plus przeglądarka, a nie same czytniki. Jedynym sposobem, by wiedzieć, że Twój produkt jest spójny dla wszystkich, jest testowanie realnych kombinacji, których używa Twoja publiczność. Ta sama zasada stoi za manualnymi audytami dostępności w ogóle: narzędzia zawężają poszukiwania, ludzie potwierdzają doświadczenie.

Co testować

Testowanie jest znacznie skuteczniejsze, gdy jest ustrukturyzowane. Oto wymiary, które mają znaczenie, mniej więcej w kolejności priorytetów, a każdy odwzorowuje się na konkretne kryteria sukcesu WCAG 2.2.

Obwieszczanie: nazwa, rola, wartość

Dla każdego elementu interaktywnego potwierdź, że czytnik obwieszcza dokładną nazwę (czym jest), poprawną rolę (przycisk, łącze, pole wyboru, karta) oraz, tam gdzie to istotne, wartość lub stan. To sedno WCAG 4.1.2 (Nazwa, rola, wartość). Nasłuchuj zwłaszcza: milczących kontrolek, kontrolek obwieszczanych tylko jako „klikalne” lub „grupa”, przycisków z ikonami bez dostępnej nazwy oraz nazw odczytywanych jako surowe ścieżki plików lub nazwy klas.

Role i stany

Stany muszą aktualizować się w miarę interakcji użytkownika. Rozwijany element, który się rozszerza, powinien przejść z „zwinięty” na „rozwinięty”; pole wyboru powinno przejść z „niezaznaczone” na „zaznaczone”; przycisk sortowania powinien obwieścić swój aktualny kierunek. Statyczny znacznik, który nigdy nie aktualizuje aria-expanded, aria-checked, aria-selected ani aria-pressed, to jedna z najczęstszych wad i ujawnia się dopiero wtedy, gdy obsługujesz widżet przy działającym czytniku.

Kolejność fokusu i zarządzanie fokusem

Przejdź klawiszem Tab przez cały interfejs. Fokus musi przemieszczać się w logicznej, przewidywalnej kolejności (WCAG 2.4.3), musi być zawsze widoczny i nigdy nie może zostać uwięziony, chyba że celowo wewnątrz okna modalnego. Trudne przypadki są dynamiczne: gdy okno dialogowe się otwiera, fokus powinien wejść do środka; gdy się zamyka, fokus powinien wrócić do elementu, który je otworzył. Pominięcie tego to najczęstszy powód, dla którego przepływ modalny jest nieużyteczny.

Kolejność czytania i nawigacji

Poza fokusem użytkownicy czytników ekranu poruszają się według struktury. Sprawdź, czy nagłówki tworzą logiczny zarys (WCAG 1.3.1), czy punkty orientacyjne (header, nav, main, footer) pozwalają użytkownikom przeskakiwać oraz czy listy i tabele są oznaczone tak, by czytnik mógł po nich nawigować i je policzyć. Sprawdź, czy sekwencja czytania odpowiada zamierzeniu wizualnemu i czy nic ważnego nie jest obwieszczane w niewłaściwej kolejności.

Obszary aktywne i aktualizacje dynamiczne

Zmiany asynchroniczne — błędy walidacji, „znaleziono 3 wyniki”, „zapisywanie…”, powiadomienia typu toast — muszą docierać do użytkownika, nie przytłaczając go. aria-live="polite" dla aktualizacji niepilnych, aria-live="assertive" tylko dla naprawdę pilnych oraz role="status" lub role="alert" dla typowych przypadków. Przetestuj, czy obszar istnieje w DOM, zanim treść się zmieni, czy aktualizacja jest obwieszczana dokładnie raz oraz czy nie przerywa użytkownikowi w połowie zdania. To wspiera WCAG 4.1.3 (Komunikaty o stanie).

Niestandardowe widżety ARIA

Wszystko, co zbudowałeś samodzielnie — menu, karty, comboboxy, selektory dat, karuzele, siatki danych, widoki drzewa — wymaga największej uwagi. Przetestuj względem ARIA Authoring Practices pod kątem oczekiwanej interakcji z klawiaturą i obwieszczeń, a następnie potwierdź, że prawdziwe czytniki rzeczywiście tak się zachowują. APG opisuje ideał; czytniki wdrażają go niedoskonale, dlatego działający wzorzec i tak musi zostać zweryfikowany w każdym czytniku.

Konkretny przykład: niedostępny vs dostępny przełącznik

Rozważ przełącznik ustawień. Wersja ostylizowana wizualnie, ale pusta semantycznie:

<div class="toggle" onclick="setNotifications()">
  <span class="dot"></span> Notifications
</div>

Dla czytnika ekranu jest to w najlepszym razie kawałek statycznego tekstu. Nie ma roli, więc nie jest obwieszczany jako kontrolka; nie ma stanu, więc użytkownik nie może stwierdzić, czy powiadomienia są włączone czy wyłączone; i nie jest w kolejności Tab, więc użytkownik klawiatury lub czytnika ekranu w ogóle nie może go dosięgnąć ani obsłużyć. Podczas testów NVDA odczytuje „Notifications” i przechodzi dalej; VoiceOver może go pominąć całkowicie.

Dostępny odpowiednik wykorzystuje natywny element i udostępnia stan:

<button type="button" aria-pressed="false" id="notif">
  Notifications
</button>

const btn = document.getElementById('notif');
btn.addEventListener('click', () => {
  const on = btn.getAttribute('aria-pressed') === 'true';
  btn.setAttribute('aria-pressed', String(!on));
});

Teraz każdy czytnik obwieszcza „Notifications, przycisk przełączający, niewciśnięty”, jest osiągalny przez Tab, obsługiwany klawiszem Enter lub spacją, a stan przełącza się słyszalnie po aktywacji. Wniosek można uogólnić: preferuj natywną semantykę, a gdy musisz użyć ARIA, przetestuj, czy każdy czytnik faktycznie respektuje rolę i stan. Wzorce takie jak ta wada brakującego stanu należą do typowych problemów z dostępnością, których należy unikać.

Zalecane pary czytnika i przeglądarki

Testuj kombinacje, których używają prawdziwi użytkownicy, a nie dowolne pary. Praktyczna macierz obejmująca zdecydowaną większość użytkowników czytników ekranu:

• NVDA + Firefox (Windows) — najczystszy punkt odniesienia do wychwytywania problemów ze znacznikami
• NVDA + Chrome (Windows) — najczęstsza para z darmowym czytnikiem w praktyce
• JAWS + Chrome (Windows) — dominująca w środowiskach korporacyjnych i rządowych
• VoiceOver + Safari (macOS) — jedyna w pełni wspierana para VoiceOver na komputerze
• VoiceOver + Safari (iOS) — mobilna, oparta na gestach, odrębny cel od komputerowego
• TalkBack + Chrome (Android) — standardowa para dla Androida

Pary mają znaczenie, ponieważ czytniki są dostrojone do konkretnych przeglądarek; VoiceOver z Chrome lub JAWS z Firefoksem daje zachowanie, które nie odzwierciedla tego, jak Twoja publiczność faktycznie doświadcza strony. Tam, gdzie Twoje analizy wskazują na konkretną publiczność — powiedzmy produkt sektora publicznego z intensywnym użyciem JAWS lub aplikację konsumencką nastawioną na urządzenia mobilne — odpowiednio zważ macierz. Nasza usługa oceny z czytnikami ekranu dostraja tę macierz do analiz każdego klienta, zamiast testować stałą listę.

Typowe pułapki

Nawet staranne zespoły potykają się o te same rzeczy. Uważaj na te:

• Testowanie z otwartymi oczami. Jeśli widzisz ekran, podświadomie nadrobisz to, czego czytnik Ci nie mówi. Wyłącz monitor albo przynajmniej odwróć wzrok i nawiguj wyłącznie słuchem.
• Testowanie tylko jednego czytnika. Omówione powyżej — to największe źródło fałszywej pewności.
• Pomijanie trybu formularzy/fokusu. W NVDA i JAWS niestandardowe widżety często wymagają, by użytkownik był we właściwym trybie. Jeśli testujesz tylko w trybie przeglądania, przeoczysz interakcje, które psują się w trybie formularzy.
• Nadużywanie aria-label. Dodawanie etykiet ARIA wszędzie może nadpisać widoczny tekst, zdesynchronizować dostępną nazwę z tym, co jest pokazane, i zmylić użytkowników sterowania głosowego. Preferuj natywne etykietowanie; sięgaj po ARIA tylko wtedy, gdy HTML nie potrafi wyrazić zależności.
• Zakładanie, że APG gwarantuje sukces. ARIA Authoring Practices opisują zamierzone zachowanie, a nie to, co robi każdy czytnik. Zawsze weryfikuj względem prawdziwych czytników.
• Ufanie widżetom nakładkowym. Nakładki i widżety „dostępności z AI”, które twierdzą, że naprawiają dostęp dla czytników ekranu w czasie działania, nie zapewniają niezawodnego doświadczenia i często pogarszają nawigację tym samym ludziom, którym rzekomo pomagają. Nie ma substytutu dla dostępnego znacznika potwierdzonego prawdziwymi testami. Audytuj faktyczny DOM i obwieszczenia, a nie marketing nakładki.
• Traktowanie urządzeń mobilnych po macoszemu. VoiceOver na iOS i TalkBack na Androidzie ujawniają własne problemy z gestami, fokusem i obszarami aktywnymi, których testowanie na komputerze nigdy nie pokazuje.

Dlaczego testowanie przez osoby z niepełnosprawnościami dodaje wartość

Samodzielne uruchomienie czytnika wychwytuje bardzo wiele — ale istnieje znacząca różnica między technicznym zaliczeniem a faktyczną użytecznością, i to właśnie tam doświadczenie życiowe ma największe znaczenie. Codzienny użytkownik czytnika ekranu nawiguje odruchowo: porusza się według nagłówków, przegląda za pomocą pokrętła, rozpoznaje, kiedy obwieszczenie jest rozwlekłe lub nadmiarowe, i natychmiast wyczuwa, gdy przepływ zmusza go do podążania nieefektywną ścieżką, nawet jeśli każdy pojedynczy element jest „zgodny”.

Widzący deweloper testujący po raz pierwszy zwykle weryfikuje obecność — „przycisk jest obwieszczany” — podczas gdy doświadczony użytkownik ocenia doświadczenie — „przycisk jest obwieszczany, ale etykieta jest niejednoznaczna, potwierdzenie nie jest wypowiadane, a dotarcie tutaj zajęło dwanaście dodatkowych przesunięć”. Te ustalenia dotyczące użyteczności rzadko pojawiają się na liście kontrolnej zgodności, a jednak to właśnie one decydują o tym, czy ktoś naprawdę może wykonać zadanie. Dlatego QualiBooth łączy zautomatyzowane oprogramowanie do skanowania dostępności i nasz zestaw narzędzi dostępności z audytami przeprowadzanymi przez osoby z niepełnosprawnościami: narzędzia znajdują to, co oczywiste, eksperci znajdują to, co naprawdę psuje doświadczenie. W przypadku produktów, które często się zmieniają, cykliczne audyty dostępności sprawiają, że ten zakres nie dryfuje między wydaniami.

Gdzie testowanie czytników ekranu pasuje w Twoim programie

Testowanie czytników ekranu to jedna z dyscyplin w ramach szerszej praktyki. Naturalnie łączy się z testowaniem wyłącznie klawiaturą oraz z adaptacyjnymi narzędziami webowymi, na których polegają Twoi użytkownicy, i daje rodzaj dowodów wspierających obowiązki prawne wynikające z EAA, ADA oraz Section 508. Ustalenia zasilają też bezpośrednio dokumentację: nasz zespół przekłada wyniki czytnik po czytniku na raporty VPAT oraz na uporządkowane według priorytetów plany naprawcze, które dostarczamy poprzez doradztwo w zakresie dostępności. Jeśli budujesz program długoterminowy, a nie jednorazową kontrolę, to właśnie ta integracja chroni dostępność przed regresją.

Podsumowanie

Czytniki ekranu nie są wymienne, a czysty zautomatyzowany raport nie jest użytecznym produktem. NVDA, JAWS, VoiceOver i TalkBack interpretują Twój znacznik na różne sposoby, parują się z różnymi przeglądarkami i ujawniają różne wady — dlatego testowanie w realnych kombinacjach używanych przez Twoją publiczność to jedyny sposób, by mieć pewność. Ułóż swoje testy wokół obwieszczeń, ról i stanów, fokusu, kolejności czytania, obszarów aktywnych i niestandardowych widżetów; preferuj natywną semantykę nad łatki ARIA; ignoruj nakładki; i wszędzie tam, gdzie to możliwe, pozwól ludziom, którzy używają tych narzędzi na co dzień, powiedzieć Ci, co naprawdę działa.

Gdy zechcesz, by tę pewność potwierdzili specjaliści, ocena z czytnikami ekranu QualiBooth testuje we wszystkich głównych czytnikach i zwraca ustalenia z dokładnymi poprawkami znaczników. Możesz też zacząć od darmowego skanu lub poprosić o demo, aby zobaczyć, gdzie Twój interfejs znajduje się dzisiaj.

FAQ

Ile czytników ekranu naprawdę muszę przetestować?

Co najmniej przetestuj NVDA, JAWS i VoiceOver na komputerze, plus VoiceOver na iOS i TalkBack na Androidzie, jeśli dostarczasz doświadczenie mobilne. Testowanie mniejszej liczby pozostawia martwe pola, ponieważ czytniki rozchodzą się w sposobie obsługi ARIA i treści dynamicznych.

Czy narzędzia automatyczne mogą zastąpić testowanie czytników ekranu?

Nie. Narzędzia automatyczne wiarygodnie wychwytują tylko część problemów — brakujący tekst alternatywny, niektóre problemy z kontrastem, pewne błędy strukturalne — ale nie potrafią ocenić, czy obwieszczenie jest jasne, czy fokus przemieszcza się sensownie ani czy zadanie da się faktycznie wykonać wyłącznie słuchem. To wymaga prawdziwego czytnika i, najlepiej, prawdziwego użytkownika.

Czy nakładki lub widżety „dostępności z AI” eliminują potrzebę testowania?

Nie. Nakładki nie zapewniają niezawodnego doświadczenia z czytnikami ekranu i często wprowadzają nowe problemy. Trwałym rozwiązaniem jest dostępny znacznik potwierdzony przez prawdziwe testy z czytnikami, a to właśnie zapewnia nasza usługa oceny z czytnikami ekranu.

Które kryteria WCAG obejmuje testowanie czytników ekranu?

Wspiera ono bezpośrednio m.in. 1.3.1 (Informacje i relacje), 2.4.3 (Kolejność fokusu), 4.1.2 (Nazwa, rola, wartość) oraz 4.1.3 (Komunikaty o stanie). Każde ustalenie z ustrukturyzowanej oceny można odwzorować na odpowiednie kryterium sukcesu WCAG 2.2.