Narzędzia do testowania dostępności strony – przegląd i porównanie

Narzędzia do testowania dostępności są dziś tak samo ważne jak linters czy testy jednostkowe – bez nich trudno realnie ocenić zgodność ze standardem WCAG i komfort użytkowników z niepełnosprawnościami.

Żadne pojedyncze narzędzie nie wystarcza: potrzebne jest połączenie automatycznych skanerów, testów manualnych, walidatorów kodu i narzędzi specjalistycznych.

Poniżej znajdziesz przegląd najważniejszych narzędzi, ich mocnych i słabych stron oraz praktyczne wskazówki, jak zbudować własny „stack” do testowania dostępności w projekcie.

Dlaczego w ogóle testować dostępność narzędziami?

Dostępność (a11y) to nie tylko etyka czy UX, ale także wymóg prawny – w wielu przypadkach konieczna jest zgodność z WCAG 2.1 na poziomie co najmniej AA.

Ręczne przejście całej strony z listą kryteriów WCAG jest możliwe, ale czasochłonne i podatne na pomyłki. Dlatego:

• narzędzia automatyczne – błyskawicznie wykrywają typowe błędy (np. brak alt, niewystarczający kontrast, błędną strukturę nagłówków);
• walidatory kodu – pomagają znaleźć problemy wynikające z niepoprawnego HTML (np. zagnieżdżanie, duplikaty id);
• narzędzia manualne i czytniki ekranu – pozwalają zobaczyć stronę z perspektywy realnych użytkowników.

W3C podkreśla, że narzędzia są wsparciem procesu, a nie zastępstwem dla testów eksperckich i z użytkownikami. Podobnie polskie wytyczne rządowe – testy automatyczne są punktem wyjścia, ale nie wyczerpują audytu.

Główne kategorie narzędzi do testowania dostępności

1. Automatyczne skanery w przeglądarce

To zwykle rozszerzenia do Chrome/Edge/Firefox lub moduły wbudowane w narzędzia deweloperskie przeglądarek. W kilka sekund generują raport dostępności dla aktualnie otwartej strony.

Typowe cechy:

• działają „na żywo” na renderowanej stronie,
• wykrywają naruszenia konkretnych kryteriów WCAG (np. 1.1.1, 1.4.3, 2.4.4),
• ułatwiają debug (podświetlanie problematycznych elementów, podgląd DOM).

Przykłady: Google Lighthouse, WAVE, Accessibility Insights for Web, axe DevTools, ARC Toolkit, ANDI, tota11y, Experte Accessibility Checker.

2. Walidatory kodu i analizatory całej witryny

Druga grupa narzędzi obejmuje dwa obszary: poprawność kodu HTML (np. W3C Markup Validation Service, Nu HTML Checker) oraz skanowanie wielu podstron w jednym przebiegu – całej witryny lub określonej domeny. Walidatory nie są stricte „a11y”, ale błędny HTML często prowadzi do problemów z dostępnością (np. nieprawidłowe nagłówki, formularze bez etykiet).

3. Narzędzia do kontrastu i kolorów

Kontrast tekstu względem tła (WCAG 1.4.3, 1.4.11) to jedna z najczęstszych przyczyn niedostępności. Do jego kontroli służy m.in. Colour Contrast Analyser (CCA) oraz wbudowane podpowiedzi kontrastu w devtools (np. w Chrome/Edge).

4. Czytniki ekranu i testy manualne

Automaty nie ocenią użyteczności czy logiki nawigacji – tu potrzebne są testy manualne i narzędzia asystujące. Podstawowe techniki to:

• test klawiaturą (TAB) – sprawdzenie, czy cała strona jest obsługiwana wyłącznie z klawiatury, fokus jest widoczny, a kolejność przechodzenia logiczna;
• test skalowania – powiększenie do 200% i ocena, czy zawartość pozostaje czytelna i nie „wysypuje się” z ekranu;
• test z czytnikiem ekranu (np. NVDA) – darmowy screen reader pozwala sprawdzić, jak strona jest odczytywana osobom niewidomym.

W polskich materiałach często zaleca się: zainstaluj NVDA, wyłącz monitor i spróbuj znaleźć konkretną informację, korzystając wyłącznie z syntezatora mowy.

5. Narzędzia do dokumentów i multimediów

Jeśli publikujesz PDF-y, prezentacje lub filmy, przydadzą się narzędzia takie jak PDF Accessibility Checker (PAC) oraz rozwiązania do dodawania napisów i transkrypcji (np. w YouTube, Vimeo lub zewnętrznych usługach).

Przegląd popularnych narzędzi – mocne i słabe strony

WAVE – szybka diagnoza błędów

WAVE (Web Accessibility Evaluation Tool) to jedno z najbardziej rozpoznawalnych narzędzi do podstawowej oceny dostępności.

• dostępne jako walidator webowy oraz rozszerzenie do Chrome/Firefox,
• wykrywa m.in. brak tekstów alternatywnych, błędy w strukturze nagłówków, problemy z formularzami, kontrastem i ARIA,
• wizualnie nakłada ikony błędów i ostrzeżeń na badaną stronę, co ułatwia ich zlokalizowanie.

Zalety: prosty interfejs, dobry na start – zrozumiały dla projektantów, devów i osób nietechnicznych. Wyraźne rozróżnienie między błędami, ostrzeżeniami a informacjami.

Ograniczenia: działa głównie na pojedynczych stronach – nie jest crawlerem całych serwisów. Nie wykrywa błędów wymagających interpretacji semantycznej (np. sensowności tekstów linków, jakości treści).

Google Lighthouse – ocena dostępności w devtools

Lighthouse to moduł wbudowany w narzędzia deweloperskie przeglądarki, który generuje raport m.in. z zakresu dostępności.

• dostępny w zakładce Audits / Lighthouse w devtools,
• generuje ocenę liczbową (score) oraz listę znalezionych problemów,
• poza dostępnością analizuje również wydajność, SEO, PWA itp.

Zalety: nie wymaga instalowania rozszerzeń – każdy dev ma go „pod ręką”. Przyjazna, zwięzła lista rekomendacji, powiązana z konkretnymi elementami DOM.

Ograniczenia: zakres testów dostępności jest ograniczony do reguł automatycznych – wiele kryteriów WCAG wymaga weryfikacji manualnej. Nie oferuje tak rozbudowanej diagnostyki a11y jak wyspecjalizowane rozszerzenia (axe, Accessibility Insights).

Accessibility Insights for Web – narzędzie od Microsoftu

Accessibility Insights for Web to zestaw narzędzi Microsoftu do testowania dostępności, dostępny jako rozszerzenie przeglądarki.

Główne tryby pracy:

• FastPass – szybkie, automatyczne testy najważniejszych problemów;
• Assessment – rozbudowana lista kroków do pełniejszej weryfikacji zgodności z WCAG;
• integracje – współpraca z innymi narzędziami deweloperskimi.

Zalety: łączy testy automatyczne z pół-manualną listą kontrolną, prowadząc krok po kroku. Dobrze sprawdza się w zespołach, które chcą wyjść poza prostą „checklistę”.

Ograniczenia: interfejs i dokumentacja po angielsku mogą stanowić barierę. Bardziej zaawansowane funkcje wymagają podstawowej znajomości WCAG.

ARC Toolkit, ANDI, tota11y, Experte – narzędzia niszowe, ale przydatne

Rozszerzenia i skryptozakładki, które uzupełniają podstawowe narzędzia:

• ARC Toolkit – rozszerzenie do Chrome z zestawem narzędzi do testowania dostępności;
• ANDI (Accessible Name and Description Inspector) – skryptozakładka do inspekcji dostępnych nazw i opisów, pokazuje, jak treści będą odczytywane przez czytniki ekranu oraz podpowiada poprawki;
• tota11y – skryptozakładka, która wizualnie oznacza m.in. strukturę nagłówków, kontrast, opisy alternatywne i sposób odczytu elementów przez screen reader;
• Experte Accessibility Checker – prosty walidator online, który po podaniu adresu analizuje stronę pod kątem dostępności.

Dobre jako uzupełnienie – nie zastąpią pełnego audytu, ale pomagają zrozumieć strukturę i semantykę z perspektywy technologii asystujących.

Colour Contrast Analyser – kontrola kontrastu

Colour Contrast Analyser (CCA) to darmowy program do porównywania dwóch kolorów i automatycznego sprawdzania wymagań kontrastu WCAG (dla tekstu zwykłego i powiększonego, poziomy AA/AAA). Można pobrać kolor z próbki ekranu lub podać wartość z kodu (hex, RGB).

Zalety: bardzo prosty, a jednocześnie precyzyjny – idealny dla projektantów UI i front-endowców. Pozwala szybko iterować nad paletą kolorów już na etapie projektu.

Ograniczenia: sprawdza wyłącznie kontrast – nie oceni, czy kolor nie jest jedynym nośnikiem informacji.

W3C Markup Validation Service i Nu HTML Checker – poprawność HTML

W3C Markup Validation Service oraz Nu HTML Checker weryfikują zgodność HTML ze standardami W3C, wskazując błędy i ostrzeżenia dotyczące składni, atrybutów i zagnieżdżeń.

Zalety: poprawny kod to podstawa działania czytników ekranu i technologii asystujących. Wiele błędów dostępności ma źródło w błędach strukturalnych HTML.

Ograniczenia: narzędzia nie „znają” WCAG – sygnalizują problemy z kodem, a nie pełną listę barier dostępności. Część ostrzeżeń wymaga interpretacji przez doświadczonego dewelopera.

NVDA – darmowy czytnik ekranu

NVDA (NonVisual Desktop Access) to bezpłatny czytnik ekranu dla Windows, powszechnie używany w testach.

Ćwiczenie warte wdrożenia: zainstaluj NVDA, wyłącz monitor i spróbuj odnaleźć ważną informację na stronie (np. numer telefonu), słuchając wyłącznie syntezatora mowy.

Zalety: darmowy i aktywnie rozwijany. Dobrze współpracuje z popularnymi przeglądarkami i aplikacjami.

Ograniczenia: wymaga nauki skrótów i sposobu „myślenia” czytnika. Testy są czasochłonne, ale to jedyny sposób na ocenę doświadczenia osoby niewidomej.

PDF Accessibility Checker – dostępność dokumentów PDF

PDF Accessibility Checker (PAC) służy do audytu plików PDF. Sprawdza zgodność z PDF/UA, analizując m.in. strukturę nagłówków, tekst alternatywny dla grafik, znaczniki języka i logiczną kolejność czytania.

Jeśli publikujesz dużo dokumentów (np. w sektorze publicznym), PAC jest praktycznie obowiązkowy w zestawie narzędzi.

Porównanie wybranych narzędzi – kiedy użyć którego?

Poniższa tabela zbiera najczęściej używane narzędzia z różnych kategorii:

Narzędzie	Typ narzędzia	Poziom trudności	W czym jest najlepsze	Główne ograniczenia
WAVE	rozszerzenie + walidator online	niski	szybka diagnoza typowych błędów na pojedynczej stronie	brak skanowania dużych serwisów, ograniczenia testów automatycznych
Lighthouse (Chrome)	moduł w devtools	niski/średni	ogólna ocena dostępności i wskazanie „oczywistych” problemów	brak pełnego pokrycia WCAG, wymaga uzupełnienia testami manualnymi
Accessibility Insights	rozszerzenie + zestaw narzędzi	średni	prowadzenie przez rozbudowaną listę testów WCAG	interfejs po angielsku, wymaga podstawowej wiedzy o WCAG
Colour Contrast Analyser	aplikacja desktopowa	niski	precyzyjne sprawdzanie kontrastu kolorów	obsługuje tylko kwestie kontrastu, resztę trzeba testować osobno
W3C Validator / Nu Checker	walidator kodu	średni	wykrywanie błędów składni HTML istotnych dla dostępności	nie jest narzędziem stricte do a11y, wymaga interpretacji wyników
NVDA	czytnik ekranu	średni/wysoki	weryfikacja realnego doświadczenia użytkownika niewidomego	wymaga nauki obsługi, testy są czasochłonne, ale kluczowe jakościowo

Jak dobrać zestaw narzędzi do swojego projektu?

Dla freelancera / małego studia

Minimalny, ale skuteczny zestaw:

• Lighthouse – do szybkiego przeskanowania każdej kluczowej podstrony,
• WAVE lub Accessibility Insights for Web – dokładniejsza diagnoza poszczególnych ekranów,
• Colour Contrast Analyser – do pracy nad paletą kolorów i komponentami UI,
• W3C Validator – okresowe sprawdzanie jakości HTML,
• NVDA – choćby podstawowa runda testów screen readerem przed wdrożeniem.

Taki zestaw znacząco ogranicza liczbę rażących błędów dostępności już na etapie developmentu.

Dla zespołu produktowego / software house’u

Warto rozszerzyć proces o integracje i reguły zespołowe:

• rozszerzyć automatyczne testy o narzędzia typu axe-core lub inne CLI / API do integracji z CI,
• włączyć Accessibility Insights jako element definition of done dla widoków o wysokiej krytyczności,
• wprowadzić cykliczne testy manualne klawiaturą i NVDA w każdym sprincie.

Dla urzędu, NGO, instytucji z dużą liczbą treści

Poza powyższymi, szczególnie ważne są:

• PDF Accessibility Checker – weryfikacja dostępności dokumentów publikowanych na BIP czy stronie głównej,
• narzędzia do skanowania dużej liczby podstron (automatyczne audyty wskazywane m.in. na gov.pl i w branżowych opracowaniach),
• gotowe listy kontrolne dla redaktorów i autorów, wspierające ręczne sprawdzanie dostępności.

Przykładowy workflow testów dostępności – krok po kroku

Poniższy schemat możesz wdrożyć w projekcie (np. przy każdym release’ie):

1. Szybkie skanowanie automatyczne

   Uruchom Lighthouse na kluczowych podstronach (home, listing, szczegóły, formularze, logowanie). Zanotuj wynik i listę błędów dostępności, popraw to, co oczywiste (kontrast, alt, role, focus).

2. Szczegółowa analiza wybranych widoków

   Użyj WAVE lub Accessibility Insights, by dogłębnie zbadać strony z dużą interakcją (formularze, koszyk, profil użytkownika). Analizuj także ostrzeżenia – często zapowiadają problemy widoczne dopiero w testach z użytkownikami.

3. Testy manualne klawiaturą

   Odłóż myszkę i przejdź całą ścieżkę użytkownika przy pomocy klawiszy TAB, Shift+TAB, Enter i spacji. Sprawdź:

   • czy fokus jest zawsze widoczny,
   • czy kolejność przechodzenia jest logiczna (od góry do dołu, od lewej do prawej),
   • czy można wyjść z modali, dropdownów i dialogów bez przeładowywania strony.

4. Test skalowania i responsywności

   Powiększ stronę do 200% i upewnij się, że treść nie „rozjeżdża się”, nie nachodzi na siebie i nie wymaga przewijania w poziomie przy typowych szerokościach viewportu.

5. Test kontrastu

   Skorzystaj z Colour Contrast Analyser, aby sprawdzić kontrast kluczowych elementów (nawigacja, przyciski, treść, komunikaty błędów). Pamiętaj o stanach hover/active/focus – one także muszą być czytelne.

6. Walidacja HTML

   Przepuść wybrane podstrony przez W3C Validator lub Nu HTML Checker, napraw błędy strukturalne (nagłówki, formularze, atrybuty ARIA).

7. Test z NVDA

   Uruchom NVDA, wyłącz monitor i spróbuj wykonać kluczowe zadania (np. rejestracja, zakup, wysłanie formularza) oraz odnaleźć istotne informacje (np. numer telefonu, adres e-mail).

   Zwróć uwagę na:

   • kolejność odczytu,
   • sensowność etykiet i tekstów linków,
   • komunikaty o błędach w formularzach.

8. Dokumenty i multimedia

   Jeśli publikujesz PDF-y, sprawdź je w PDF Accessibility Checker (struktury nagłówków, znaczniki języka, teksty alternatywne). Dla wideo zweryfikuj:

   • czy mają napisy,
   • czy odtwarzacz jest obsługiwalny klawiaturą,
   • czy istnieją alternatywy w postaci transkrypcji lub audiodeskrypcji (w razie potrzeby).

Najczęstsze błędy przy korzystaniu z narzędzi dostępności

1. Poleganie wyłącznie na jednym narzędziu
   W3C i polskie wytyczne jasno wskazują, że pojedyncze narzędzie nie wykryje wszystkich problemów – potrzebna jest kombinacja rozwiązań i testów manualnych.

2. Traktowanie wyniku procentowego jako „certyfikatu”
   Wynik 90–100% w Lighthouse czy innym skanerze nie oznacza pełnej zgodności z WCAG – wiele kryteriów wymaga oceny jakościowej (np. zrozumiałość treści, sensowność kolejności focusa).

3. Ignorowanie ostrzeżeń („warnings”)
   WAVE i inne narzędzia często oznaczają potencjalne problemy jako ostrzeżenia – to zwykle miejsca, które warto sprawdzić ręcznie, zwłaszcza w newralgicznych częściach interfejsu.

4. Brak testów z klawiaturą i czytnikiem ekranu
   Automatyczne narzędzia nie ocenią logiki interakcji, zachowania modali, czytelności komunikatów błędów czy faktycznej nawigowalności strony.

5. Pominięcie treści dodatkowych: PDF, wideo, załączniki
   Audyt strony HTML to dopiero część pracy – użytkownicy często największe problemy mają z niedostępnymi dokumentami i multimediami, które należy sprawdzać np. PAC oraz kontrolą napisów i transkrypcji.