Czytniki ekranu wyjaśnione: jak niewidomi użytkownicy poruszają się po sieci

Szacuje się, że na świecie żyje 36 milionów osób niewidomych, a około 217 milionów kolejnych ma umiarkowane lub poważne zaburzenia widzenia. Mimo to w 2025 roku ponad 96% stron internetowych wciąż ma co najmniej jedną wykrywalną barierę dostępności. Dla niewidomej osoby polegającej na czytniku ekranu jeden brakujący opis, złamana hierarchia nagłówków czy niedostępny CAPTCHA mogą stanowić różnicę między samodzielnym wykonaniem zadania a całkowitym porzuceniem Twojej witryny. Zrozumienie, jak czytniki ekranu faktycznie działają — nie tylko w teorii, ale w praktyce — jest fundamentem budowania dostępnej sieci.

Czym jest czytnik ekranu i kto z niego korzysta?

Czytnik ekranu to oprogramowanie wspomagające, które przekształca treści wyświetlane na ekranie w syntezowaną mowę lub w wyjście na brajlowskim monitorze brajlowskim. Zamiast po prostu czytać tekst na głos, czytniki ekranu interpretują strukturę, role, stany i relacje elementów interfejsu, dając użytkownikom pełne zrozumienie strony internetowej bez polegania na prezentacji wizualnej. Myśl o nim mniej jak o lektorze, a bardziej jak o inteligentnym tłumaczu, który przekłada cały Twój wizualny interfejs na dźwiękowy lub dotykowy strumień informacji.

Czytniki ekranu są używane przede wszystkim przez osoby niewidome lub słabowidzące, ale wspierają też użytkowników z niektórymi niepełnosprawnościami poznawczymi lub trudnościami w czytaniu. Według 10. ankiety WebAIM dotyczącej użytkowników czytników ekranu — przeprowadzonej pod koniec 2023 roku i opublikowanej w lutym 2024 — prawie 77% użytkowników czytników ekranu to osoby niewidome, a niemal 20% stanowią osoby słabowidzące lub z innymi zaburzeniami widzenia. Ubytek słuchu, niepełnosprawności poznawcze i niepełnosprawności ruchowe odpowiadają za pozostałą część. Nie jest to niszowa grupa: 4,9% dorosłych w USA ma niepełnosprawność wzroku związaną z niewidomością lub poważnymi trudnościami z widzeniem, a globalna liczba użytkowników z niepełnosprawnością wzroku liczona jest w setkach milionów.

Warto też zauważyć, że użytkownicy czytników ekranu nie są jednorodną grupą. Badania konsekwentnie pokazują ogromne zróżnicowanie umiejętności, preferencji, strategii nawigacji i sposobów rozwiązywania problemów. Osoba niewidoma od urodzenia, korzystająca z JAWS od dwudziestu lat, porusza się po stronach zupełnie inaczej niż ktoś, kto niedawno stracił wzrok i dopiero uczy się technologii wspomagających. Nawet technicznie dostępne strony mogą stwarzać poważne trudności, gdy modele mentalne, których wymagają, nie pokrywają się z oczekiwaniami użytkownika. Projektanci i deweloperzy muszą oprzeć się pokusie wyobrażania sobie jednego, archetypicznego użytkownika czytnika ekranu.

Jak czytniki ekranu naprawdę działają: drzewo dostępności

Aby naprawdę zrozumieć czytniki ekranu, musisz zrozumieć, co one czytają — a nie jest to Twój układ wizualny. Czytniki ekranu działają, uzyskując dostęp do drzewa dostępności, czyli strukturalnej reprezentacji strony, którą przeglądarka buduje na podstawie drzewa DOM HTML. Przeglądarka udostępnia to drzewo poprzez specyficzne dla platformy API dostępności: UI Automation w systemie Windows, NSAccessibility w macOS i AccessibilityService w Androidzie. Czytnik ekranu odpyta to API, otrzymuje informacje semantyczne o każdym elemencie i przekształca je w mowę lub wyjście brajlowskie.

Ma to kluczową konsekwencję: to, co widzisz na ekranie, i to, co postrzega czytnik ekranu, może się radykalnie różnić. Jeśli Twój projekt wizualny używa elementu <div> ostylowanego tak, by wyglądał jak przycisk, czytnik ekranu nie ogłosi go jako przycisku — ponieważ nie ma on roli przycisku w drzewie dostępności. Czytnik ekranu ogłasza to, co mówi kod, a nie to, co pokazują piksele. Semantyczne elementy HTML, takie jak <button>, <nav>, <h1> i <form>, mają wbudowane role, które są automatycznie ujawniane w drzewie dostępności. Gdy deweloperzy omijają je na rzecz ogólnych elementów łatanych rolami ARIA, tworzą niepotrzebną złożoność i często wprowadzają nowe błędy.

Czytniki ekranu dostarczają też kontekstu, który nie jest widoczny na ekranie. Gdy użytkownik napotyka listę, czytnik ogłasza, ile zawiera ona elementów. Gdy dociera do tabeli, ogłasza liczbę wierszy i kolumn. Gdy fokus przechodzi do pola formularza, czytnik odczytuje etykietę pola, jego typ i aktualny stan. Ta kontekstowa metadana jest całkowicie zależna od dobrze zbudowanego, semantycznego HTML. Jeśli ją usuniesz, odbierasz użytkownikowi możliwość zrozumienia, z czym ma do czynienia.

Najważniejsze czytniki ekranu: JAWS, NVDA, VoiceOver i TalkBack

Rynek czytników ekranu jest zdominowany przez kilka narzędzi, z których każde ma odrębne cechy. Zrozumienie, z których narzędzi najprawdopodobniej korzystają Twoi użytkownicy, bezpośrednio wpływa na to, jak powinieneś testować swoją stronę.

JAWS (Job Access With Speech), opracowany przez Freedom Scientific i po raz pierwszy wydany w 1995 roku, od dawna uważany jest za branżowy złoty standard, szczególnie w zastosowaniach korporacyjnych. W ankiecie WebAIM 2024 JAWS był głównym czytnikiem ekranu dla około 41% respondentów. Jest to produkt komercyjny, z kosztami licencji od 90 do ponad 1 400 dolarów rocznie. JAWS oferuje szerokie możliwości dostosowania, solidną kompatybilność ze złożonymi przepływami pracy w Microsoft Office i aplikacjach profesjonalnych oraz „Browse Mode”, który przekształca stronę w nawigowalne, liniowe środowisko, pozwalające użytkownikom przeskakiwać między nagłówkami, punktami orientacyjnymi i polami formularzy za pomocą intuicyjnych skrótów klawiaturowych.

NVDA (NonVisual Desktop Access), opracowany przez NV Access i wprowadzony w 2006 roku, to darmowy, otwartoźródłowy czytnik ekranu dla systemu Windows. W 2024 roku był głównym czytnikiem ekranu dla około 38% respondentów ankiety WebAIM — niemal tyle samo co JAWS. NVDA zyskał dużą popularność dzięki bezpłatnemu modelowi, częstym aktualizacjom i solidnej wydajności. W 2025 roku NVDA wprowadził ulepszoną obsługę zarządzania fokusem w aplikacjach jednostronicowych, pomagając użytkownikom zrozumieć, kiedy treść się zmieniła i gdzie przeniósł się fokus. Zalecanym zestawem jest NVDA z przeglądarką Firefox, choć wsparcie dla Chrome również jest mocne.

VoiceOver to wbudowany czytnik ekranu Apple, dostępny w systemach macOS, iOS i iPadOS — bez konieczności instalacji. Na komputerach stacjonarnych używa skrótów klawiaturowych z modyfikatorem VO (Control + Option), natomiast w iOS opiera się na gestach dotykowych, takich jak przesunięcie, dwukrotne stuknięcie i rotor. Na urządzeniach mobilnych VoiceOver jest najczęściej używanym czytnikiem ekranu — korzysta z niego 70,6% użytkowników mobilnych czytników ekranu. Najlepiej działa w parze z Safari, która jest jedyną przeglądarką w pełni udostępniającą API dostępności macOS/iOS dla VoiceOver.

TalkBack to wbudowany czytnik ekranu Androida, oferujący komunikaty głosowe i wibracje, które pomagają użytkownikom nawigować po urządzeniach. Jest standardowym narzędziem do testowania na urządzeniach mobilnych z Androidem i najlepiej współpracuje z Chrome. System Windows jest również dostarczany z Narrator, wbudowanym czytnikiem ekranu, który stale się poprawia, ale nadal brakuje mu niektórych funkcji JAWS i NVDA. Każde z tych narzędzi zachowuje się nieco inaczej — wzorzec, który działa poprawnie w NVDA, może zawieść w JAWS — dlatego testowanie w wielu czytnikach ekranu jest niezbędne w każdym poważnym programie dostępności.

Jak niewidomi użytkownicy naprawdę nawigują: model mentalny, który zmienia wszystko

Oto spostrzeżenie, które w najbardziej fundamentalny sposób zmienia sposób, w jaki deweloperzy powinni myśleć o swojej pracy: użytkownicy czytników ekranu nie czytają stron liniowo od góry do dołu. Używają zaawansowanego zestawu strategii nawigacji, aby skanować i przeskakiwać po treści w sposób efektywny, podobnie jak użytkownik widzący pobieżnie skanuje wzrokiem. Jeśli nie wesprzesz tych strategii, nawet technicznie dostępna strona staje się wyczerpującym, nieużywalnym doświadczeniem.

Najpowszechniejszą strategią nawigacji jest nawigacja po nagłówkach. Wykorzystanie nagłówków do wyszukiwania informacji wzrosło z czasem i pozostaje dominującą metodą — 88,8% respondentów ankiety uznaje poziomy nagłówków za bardzo lub raczej przydatne. Zaawansowani użytkownicy znacznie częściej nawigują po nagłówkach niż początkujący. W praktyce oznacza to, że użytkownik naciska klawisz H w JAWS lub NVDA, aby przejść do następnego nagłówka na stronie, szybko skanując jej strukturę. Naciśnięcie klawiszy 1 do 6 przenosi bezpośrednio do nagłówka danego poziomu. Jeśli Twoja strona nie ma nagłówków lub używa nagłówków dobranych pod kątem rozmiaru wizualnego, a nie struktury dokumentu, niewidomi użytkownicy nie mają punktów orientacyjnych, między którymi mogliby przeskakiwać — są zmuszeni wysłuchać całą stronę od początku.

Drugą główną strategią jest nawigacja po punktach orientacyjnych. Elementy punktów orientacyjnych HTML5 — <main>, <nav>, <header>, <footer>, <aside> oraz <section> z etykietą — tworzą nazwane regiony, między którymi użytkownicy czytników ekranu mogą przeskakiwać za pomocą rotora lub klawiszy skrótów punktów orientacyjnych. W 2025 roku adopcja punktów orientacyjnych ARIA nieznacznie wzrosła, na czele z rosnącym użyciem natywnego elementu <main>, obecnego już na 47% stron. Choć 31,7% respondentów wskazuje, że zawsze lub często korzysta z punktów orientacyjnych, gdy są dostępne, tylko 3,7% używa ich jako głównej metody nawigacji — sugeruje to, że punkty orientacyjne są narzędziem drugorzędnym, ale ważnym dla orientacji.

Użytkownicy nawigują także po linkach, polach formularzy i przyciskach za pomocą jednoklawiszowych skrótów i często wywołują listy elementów — okno dialogowe pokazujące wszystkie nagłówki, wszystkie linki lub wszystkie pola formularzy na stronie naraz — aby przeskanować je i przeskoczyć bezpośrednio do tego, czego potrzebują. To zachowanie ma ogromne konsekwencje dla tekstów linków. Lista linków brzmiących „Czytaj więcej, Czytaj więcej, Czytaj więcej” nie ma żadnej wartości nawigacyjnej. Każdy link i przycisk musi mieć opisową, unikalną nazwę dostępną, która ma sens poza kontekstem.

Na urządzeniach mobilnych paradygmat przesuwa się w stronę gestów dotykowych. Użytkownicy VoiceOver i TalkBack przesuwają palcem w prawo, aby przejść do następnego elementu, dwukrotnie stukają, aby go aktywować, i używają gestów rotora, aby przełączać tryby nawigacji. Preferencja dla korzystania z aplikacji mobilnych wzrosła do 58% w 2024 roku, z 51,8% w 2021. Oznacza to, że Twój projekt responsywny i dostępność mobilna nie są dodatkami opcjonalnymi — to podstawowe scenariusze użycia dla dużej części użytkowników czytników ekranu.

Najbardziej problematyczne bariery w sieci dziś

Ankieta WebAIM poprosiła respondentów o wskazanie najbardziej problematycznych elementów, na które natrafiają. Wyniki są zadziwiająco spójne w ponad dekadzie badań — i stanowią bezpośrednią listę kontrolną tego, co Twoja strona musi zrobić dobrze.

• CAPTCHA jest z dużą przewagą najczęstszą skargą. Użytkownicy czytników ekranu zgodnie twierdzą, że CAPTCHA jest najbardziej problematycznym elementem od ponad czternastu lat z rzędu. Tradycyjny CAPTCHA jest oczywiście problematyczny dla osób niewidomych, ponieważ czytniki ekranu, na których polegają, nie są w stanie przetworzyć obrazu, uniemożliwiając im odczytanie informacji wymaganych przez formularz. Nawet dźwiękowe CAPTCHA zawodzą wielu użytkowników — celowe zniekształcenia czynią je niezrozumiałymi. Praktyczna rekomendacja: stosuj niewidoczną, opartą na zachowaniu weryfikację, taką jak reCAPTCHA v3 lub techniki honeypot, wszędzie tam, gdzie to możliwe.
• Elementy interaktywne o nieoczekiwanym zachowaniu — menu, zakładki, okna dialogowe i niestandardowe widżety, które nie przestrzegają ustalonych wzorców interakcji klawiaturowej — są tuż za CAPTCHA. Elementy te są często budowane z nadmiarem atrybutów ARIA i mają nieregularne zachowanie interakcji oraz problemy z kompatybilnością między przeglądarkami i czytnikami ekranu.
• Niejasne linki i przyciski nieustannie frustrują użytkowników. Zwroty takie jak „kliknij tutaj”, „dowiedz się więcej” czy „czytaj więcej” nie dają żadnej wskazówki co do miejsca docelowego lub działania, gdy są słyszane w oderwaniu od listy linków.
• Nieoczekiwane zmiany na ekranie — dynamiczne aktualizacje treści, które zachodzą bez ostrzeżenia — dezorientują niewidomych użytkowników, którzy nie mają wizualnej wskazówki, że coś się zmieniło. Jest to szczególnie dotkliwe w aplikacjach jednostronicowych zbudowanych w React, Vue lub Angular, gdzie treść może się zmieniać bez przeładowania strony.
• Uszkodzone hierarchie nagłówków podważają główną strategię nawigacji większości zaawansowanych użytkowników. Około 39% stron internetowych ma uszkodzone hierarchie nagłówków, co utrudnia użytkownikom czytników ekranu prawidłową nawigację po treści.
• Brakujący lub niewystarczający tekst alternatywny przy obrazach. Gdy tekst alternatywny jest nieobecny, czytnik ekranu może jedynie zasygnalizować obecność obrazu bez opisania jego treści lub — co gorsza — odczytać bezsensowną nazwę pliku, taką jak „IMG_4823.jpg”.

Większość — 67% — użytkowników czytników ekranu nigdy lub rzadko kontaktuje się z właścicielami stron w sprawie barier. Po prostu odchodzą. Nie otrzymasz skargi. Po prostu stracisz użytkownika.

Pisanie kodu, który czytniki ekranu są w stanie faktycznie zinterpretować

Zrozumienie wzorców nawigacji użytkowników sprawia, że wymagania techniczne stają się znacznie bardziej konkretne. Każda decyzja, którą podejmujesz w HTML i JavaScript, ma bezpośrednią, słyszalną konsekwencję dla niewidomych użytkowników. Oto zasady, które mają największe znaczenie.

Semantyczny HTML jest Twoim pierwszym i najpotężniejszym narzędziem. Pierwsza zasada ARIA mówi: „Jeśli możesz użyć natywnego elementu HTML lub atrybutu z wbudowaną semantyką i zachowaniem, których potrzebujesz, zamiast zmieniać przeznaczenie elementu i dodawać rolę, stan lub właściwość ARIA, aby uczynić go dostępnym, zrób to.” Elementy takie jak <button>, <nav>, <header> i <form> mają dostępność wbudowaną. Używanie natywnych kontrolek zapewnia kompatybilność z przeglądarkami i technologiami wspomagającymi od razu, bez dodatkowego kodu.

ARIA jest uzupełnieniem, a nie substytutem. ARIA (Accessible Rich Internet Applications) to zestaw atrybutów HTML zaprojektowanych tak, aby wypełniać luki w dostępności tam, gdzie sam HTML nie jest w stanie wyrazić wymaganej semantyki — na przykład, aby uczynić niestandardowy suwak dostępnym, ogłaszać dynamiczne zmiany treści lub wskazywać, że rozwijane menu jest aktualnie rozwinięte. Niebezpieczeństwo tkwi w nadużyciu. Strony główne z ARIA mają średnio ponad dwukrotnie więcej błędów dostępności niż strony bez ARIA. Więcej ARIA nie oznacza większej dostępności — często oznacza więcej błędów. Strony, które używały ARIA nieprawidłowo, miały o 70% więcej wykrywalnych błędów niż te, które jej nie używały. Stosuj ARIA chirurgicznie, tam, gdzie żaden natywny element nie jest w stanie wykonać zadania.

Poniższy przykład kodu ilustruje różnicę między niedostępnym niestandardowym przyciskiem a prawidłowo dostępnym:

<!-- Inaccessible: a div with click handler, no role, no keyboard support -->
<div class='btn' onclick='submitForm()'>Submit</div>

<!-- Accessible: native button with built-in role, keyboard support, and focus -->
<button type='submit'>Submit</button>

<!-- If you must use a non-button element, add role, tabindex, and keyboard event -->
<div role='button' tabindex='0'
     aria-label='Submit the registration form'
     onkeydown='handleKey(event)'
     onclick='submitForm()'>
  Submit
</div>

Regiony na żywo ARIA są właściwym mechanizmem ogłaszania dynamicznych zmian treści. Gdy Twoja strona aktualizuje treść bez pełnego przeładowania — komunikat walidacji formularza, suma w koszyku, powiadomienie — ta zmiana jest dla użytkownika czytnika ekranu niesłyszalna, jeśli nie użyjesz regionu na żywo. Atrybut aria-live='polite' instruuje czytnik ekranu, aby ogłosił zmianę po zakończeniu bieżącej aktywności użytkownika, podczas gdy aria-live='assertive' przerywa natychmiast — używaj tego drugiego oszczędnie, tylko dla pilnych alertów. W 2025 roku około 33% stron używa atrybutu aria-live, co stanowi wzrost o 4% w porównaniu z 2024, ale adopcja wciąż jest zdecydowanie zbyt niska, biorąc pod uwagę liczbę wdrożonych interfejsów dynamicznych.

Zarządzanie fokusem w komponentach interaktywnych — oknach modalnych, rozwijanych menu, akordeonach — musi być obsłużone wprost. Gdy otwiera się okno modalne, fokus musi zostać przeniesiony do jego wnętrza. Gdy się zamyka, fokus musi wrócić do elementu, który je wywołał. Użytkownik czytnika ekranu, który otwiera okno modalne i stwierdza, że fokus nadal znajduje się na przycisku za nim, jest w praktyce odcięty od treści okna dialogowego.

Testowanie Twojej strony z użyciem czytnika ekranu

Zautomatyzowane skanery dostępności są wartościowe, ale ograniczone. Narzędzia automatyczne wychwytują 30–40% naruszeń WCAG, ale prawdziwe testy z użyciem technologii wspomagających ujawniają, jak użytkownicy faktycznie doświadczają Twojej strony — brakujący kontekst, mylącą nawigację i interakcje, które po prostu nie działają. Żaden skaner nie powie Ci, że nagłówek Twojego okna modalnego nie ma sensu bez otaczającego kontekstu wizualnego ani że Twój niestandardowy rozwijany komponent ogłasza swój stan nieprawidłowo w jednej kombinacji przeglądarka–czytnik ekranu, a w innej nie.

Praktycznym punktem wyjścia dla większości zespołów jest NVDA z Firefox — darmowy, szeroko używany i skuteczny w wychwytywaniu zdecydowanej większości typowych problemów. Dodaj VoiceOver z Safari, aby objąć użytkowników macOS i iOS. W kontekstach korporacyjnych lub u klientów z wysokimi wymaganiami zgodności uwzględnij JAWS z Chrome lub Edge. Każdy czytnik ekranu najlepiej działa z określoną przeglądarką; użycie niewłaściwej kombinacji może dawać mylące wyniki testów.

Podczas testowania przyjmij wzorce nawigacji, których używają prawdziwi użytkownicy. Nie używaj myszy. Nawiguj po nagłówkach za pomocą klawisza H. Wywołaj listę linków i upewnij się, że każdy link ma sens poza kontekstem. Przechodź klawiszem Tab po polach formularzy i sprawdź, czy każda etykieta jest poprawnie ogłaszana. Otwieraj okna modalne i weryfikuj, czy fokus przechodzi do ich wnętrza. Wypełniaj formularze i wysyłaj je, słuchając każdego komunikatu walidacyjnego. Wyłącz monitor i spróbuj wykonać reprezentatywne zadanie użytkownika od początku do końca — to doświadczenie, jakkolwiek niewygodne dla testera widzącego, jest codzienną rzeczywistością Twoich niewidomych użytkowników.

Ważne jest również testowanie z użyciem rzeczywistej technologii wspomagającej, a nie emulatorów czy symulatorów przeglądarki. Panele dostępności w narzędziach deweloperskich przeglądarki pokazują drzewo dostępności, co jest przydatne przy debugowaniu, ale nie odtwarzają doświadczenia słuchowego ani nie ujawniają niuansów interakcji, które pojawiają się tylko przy użyciu prawdziwego oprogramowania czytnika ekranu.

Biznesowy i prawny argument, którego nie możesz zignorować

Jeśli moralny argument za dostępnością wymaga wzmocnienia realiami biznesowymi, liczby są bezlitosne. W samych Stanach Zjednoczonych żyje około 7 milionów osób z niepełnosprawnościami wzroku, co stanowi znaczącą bazę konsumencką. Globalnie 26% dorosłych w USA ma niepełnosprawności, co przekłada się na szacunkowo 13 bilionów dolarów potencjału rynkowego. Gdy niedostępny projekt wyklucza niewidomych użytkowników z Twojej strony, nie tylko zawodzisz moralnie — odmawiasz obsługi klientom i narażasz swoją organizację na ryzyko prawne.

WCAG 2.2 jest obecnie przywoływanym standardem prawnym w tysiącach pozwów na podstawie ADA, a Europejski Akt o Dostępności, który wszedł w pełni w życie dla firm sektora prywatnego w czerwcu 2025 roku, rozszerza wymagania zgodności na całą UE. Większość użytkowników czytników ekranu nigdy nie kontaktuje się z właścicielami stron w sprawie barier — po prostu odchodzi i przenosi swoje wydatki gdzie indziej. 67% użytkowników, którzy nigdy nie zgłaszają problemów, nie jest zadowolonych; są pokonani. Wbudowanie kompatybilności z czytnikami ekranu w proces tworzenia oprogramowania od samego początku pozwala uniknąć kosztownych działań naprawczych, zmniejsza ryzyko prawne i otwiera Twoje produkty na odbiorców, którzy aktywnie poszukują cyfrowych doświadczeń, z których naprawdę mogą korzystać.

Kluczowe wnioski

• Czytniki ekranu nawigują po strukturze, nie po wizualiach. Odpytują drzewo dostępności przeglądarki za pośrednictwem platformowych API dostępności. Semantyczny HTML — poprawne nagłówki, punkty orientacyjne, natywne kontrolki — to pojedyncza inwestycja o największej dźwigni, jaką możesz poczynić dla kompatybilności z czytnikami ekranu.
• Niewidomi użytkownicy nawigują po nagłówkach, punktach orientacyjnych i listach elementów — nie liniowo. Ponad 88% użytkowników czytników ekranu uznaje poziomy nagłówków za bardzo lub raczej przydatne w nawigacji. Uszkodzona lub brakująca hierarchia nagłówków jest jednym z najczęstszych i najbardziej szkodliwych błędów dostępności w sieci.
• ARIA wzmacnia zarówno dobry, jak i zły kod. Strony z ARIA mają średnio ponad dwukrotnie więcej błędów dostępności niż strony bez niej. Używaj ARIA tylko tam, gdzie natywny HTML nie jest w stanie wyrazić wymaganej semantyki, i zawsze testuj z użyciem prawdziwej technologii wspomagającej po jej wdrożeniu.
• CAPTCHA, niejasne linki i nieogłaszane dynamiczne zmiany treści to najpoważniejsze bariery w realnym świecie. Zastąpienie wizualnego CAPTCHA weryfikacją opartą na zachowaniu, pisanie opisowych tekstów linków i przycisków oraz wdrożenie regionów na żywo ARIA dla dynamicznych aktualizacji natychmiast i mierzalnie poprawi użyteczność dla niewidomych użytkowników.
• Testuj z użyciem prawdziwych czytników ekranu w wielu kombinacjach przeglądarek. Zautomatyzowane skanery wychwytują tylko 30–40% naruszeń WCAG. NVDA z Firefox i VoiceOver z Safari obejmują większość Twojej bazy użytkowników przy zerowym koszcie, a doświadczenie nawigowania po Twojej stronie bez myszy ujawnia problemy, których żadne narzędzie automatyczne nie jest w stanie wykryć.