Darmowe narzędzia do testowania WCAG: co sprawdzają, a czego nie

Darmowe narzędzia do WCAG są świetne do pierwszego skanu, ale nie potwierdzają pełnej zgodności strony. Automaty dobrze łapią brakujące etykiety, słaby kontrast, puste linki, błędy ARIA i problemy strukturalne. Nie ocenią jednak, czy tekst alternatywny naprawdę ma sens, czy instrukcja jest zrozumiała i czy cały proces da się przejść bez frustracji.

Najlepszy audyt dostępności łączy kilka narzędzi z testem ręcznym: klawiatura, mobile, czytnik ekranowy, formularze, komunikaty błędów i realne zadania użytkownika. Poniżej masz praktyczny zestaw, od którego warto zacząć.

Narzędzia, od których warto zacząć

Narzędzie	Co sprawdza dobrze?	Limit
Lighthouse	Podstawy dostępności, nazwy elementów, kontrast, strukturę.	To szybki skan, nie pełny audyt WCAG.
WAVE	Wizualne oznaczenie błędów na stronie.	Wymaga interpretacji, bo nie każdy alert jest krytyczny.
axe DevTools	Błędy techniczne, ARIA, etykiety, relacje elementów.	Nie ocenia jakości treści i sensu procesu.
ANDI	Dokładną kontrolę etykiet, focusu i semantyki.	Jest bardziej techniczne dla początkujących.
ARC Toolkit	Testy dostępności bezpośrednio w przeglądarce.	Najlepiej działa jako część procesu QA, nie jedyny test.

Co automaty wykrywają dobrze?

• Brakujące lub puste etykiety formularzy.
• Przyciski i linki bez dostępnej nazwy.
• Obrazy bez altu, gdy narzędzie uzna je za informacyjne.
• Część problemów z kontrastem tekstu.
• Błędy ARIA i niepoprawne role.
• Nieprawidłową strukturę nagłówków.
• Elementy interaktywne, których czytnik ekranowy nie rozumie.

Czego narzędzia nie zrobią za Ciebie?

Obszar	Dlaczego potrzebny jest człowiek?	Jak testować?
Jakość altów	Automat widzi, że alt istnieje, ale nie wie, czy opis ma sens.	Porównaj alt z funkcją obrazu na stronie.
Logika formularza	Narzędzie nie wie, czy komunikat błędu pomaga użytkownikowi.	Wyślij formularz z błędami i przeczytaj komunikaty.
Obsługa klawiaturą	Skan nie zawsze wykryje problem z kolejnością i popupami.	Przejdź cały proces klawiszem Tab.
Treść instrukcji	Poprawny HTML nie znaczy, że użytkownik rozumie, co zrobić.	Sprawdź teksty przy CTA, polach i błędach.
Proces zakupowy	Automat może nie przejść koszyka lub płatności.	Wykonaj test zadaniowy od produktu do checkoutu.

Prosty workflow audytu WCAG

1. Wybierz 5-10 reprezentatywnych URL-i: home, usługa, blog, kontakt, formularz, sklep lub narzędzie.
2. Uruchom Lighthouse i zapisz najważniejsze błędy.
3. Sprawdź te same URL-e w WAVE lub axe DevTools.
4. Przejdź stronę samą klawiaturą.
5. Sprawdź formularze: etykiety, wymagane pola, błędy, sukces.
6. Zweryfikuj obrazy i teksty alternatywne.
7. Ułóż poprawki według wpływu na użytkownika, nie według samej liczby alertów.

Matryca priorytetów

Priorytet	Przykład	Dlaczego pilne?
Krytyczny	Nie da się wysłać formularza bez myszki.	Użytkownik nie może wykonać celu strony.
Wysoki	Przyciski nie mają nazw dostępnych dla czytnika.	Osoba korzystająca z technologii wspomagających nie wie, co kliknąć.
Wysoki	Kontrast tekstu w CTA jest zbyt niski.	Treść może być nieczytelna i traci konwersję.
Średni	Nieidealna kolejność nagłówków.	Utrudnia skanowanie strony, ale nie zawsze blokuje zadanie.
Niski	Drobne ostrzeżenia bez wpływu na główny proces.	Warto naprawić, ale po usunięciu blokad.

WCAG 2.1 czy WCAG 2.2?

Wiele artykułów i narzędzi nadal mówi o WCAG 2.1, ale w praktyce coraz częściej trzeba patrzeć też na WCAG 2.2. Nie oznacza to, że stary test jest bezużyteczny. Oznacza to, że przy poważnym audycie warto sprawdzić aktualne wymagania i nie opierać się wyłącznie na jednym wyniku z automatu.

Jeżeli strona jest firmowa, usługowa albo sklepowa, dostępność warto traktować jako część jakości strony: lepsza czytelność, mniej barier, lepsze formularze, mocniejszy UX i mniej utraconych zapytań. To naturalnie łączy się z budową strony internetowej i jej późniejszą optymalizacją.

Audyt w 60 minut: praktyczny plan

Jeżeli nie masz czasu na pełny audyt, zrób krótką wersję, która złapie najdroższe błędy. To nie będzie certyfikat zgodności, ale często wystarczy, żeby znaleźć problemy blokujące użytkowników.

Czas	Działanie	Wynik
10 min	Wybierz najważniejsze URL-e i cele użytkownika.	Lista stron do testu.
15 min	Uruchom Lighthouse i WAVE.	Lista błędów automatycznych.
15 min	Przejdź menu i formularz samą klawiaturą.	Blokery dostępności i UX.
10 min	Sprawdź obrazy, alty i nagłówki.	Błędy treści i struktury.
10 min	Ułóż priorytety napraw.	Krótka kolejka: krytyczne, wysokie, średnie.

Jak raportować wyniki bez straszenia klienta?

Nie wysyłaj surowego zrzutu z narzędzia jako gotowego audytu. Klient potrzebuje wiedzieć, co realnie przeszkadza użytkownikowi i co naprawić najpierw. Zamiast „37 błędów dostępności” napisz: formularz kontaktowy nie ma czytelnych etykiet, przycisk wysyłki nie ma dostępnej nazwy, a menu nie obsługuje klawiatury. To są konkretne prace, które da się wycenić i wdrożyć.

FAQ

Czy Lighthouse wystarczy do audytu WCAG?

Nie. Lighthouse jest dobrym szybkim testem, ale wykrywa tylko część problemów. Pełniejszy audyt wymaga testu klawiaturą, formularzy, treści, altów i czasem czytnika ekranowego.

Które darmowe narzędzie jest najlepsze?

Nie ma jednego najlepszego. Lighthouse jest szybki, WAVE jest czytelny wizualnie, axe DevTools dobrze wykrywa błędy techniczne, a ANDI pomaga wejść głębiej w semantykę i etykiety.

Czy wynik 100 w Lighthouse oznacza zgodność z WCAG?

Nie. Wynik 100 oznacza, że strona przeszła zestaw automatycznych testów Lighthouse. To dobry sygnał, ale nie certyfikat zgodności.

Od czego zacząć poprawki?

Od rzeczy, które blokują wykonanie zadania: menu, formularze, CTA, koszyk, popupy, kontrast głównych tekstów i obsługę klawiaturą. Dopiero potem porządkuj mniej krytyczne ostrzeżenia.