Automatyczny test WCAG a audyt manualny – to porównanie wraca zawsze, gdy trzeba zdecydować, jak sprawdzić dostępność strony i ile na to przeznaczyć. Łatwo potraktować obie metody jak tańszą i droższą wersję tej samej usługi, ale to błąd: każda odpowiada na inne pytanie.
Automat sprawdza, czy kod spełnia reguły, które da się zweryfikować maszynowo. Człowiek ocenia, czy stroną da się naprawdę posłużyć – klawiaturą, z czytnikiem ekranu, przy powiększeniu. Poniżej zobaczysz na przykładach, gdzie kończy się jedna metoda, a zaczyna druga, i jak je połączyć.
Czym jest automatyczny test WCAG
Narzędzie, np. oparte na silniku axe-core, otwiera stronę – najlepiej w prawdziwej przeglądarce, po wykonaniu skryptów – i porównuje jej kod z zestawem reguł. Sprawdza m.in. obecność tekstów alternatywnych, powiązanie etykiet z polami, wyliczony kontrast kolorów oraz poprawność ról i atrybutów ARIA.
Test trwa chwilę, daje powtarzalne wyniki i można go uruchomić na setkach podstron albo przy każdym wdrożeniu. Ma jednak ograniczenie: widzi tylko to, co jest w kodzie w chwili skanu. Bez zaprogramowanego scenariusza nie otworzy menu, nie wyśle formularza z błędem i nie oceni, czy treść ma sens. Jak czytać wynik, wyjaśniamy w artykule test WCAG online – co sprawdza automat.
Czym jest audyt manualny
W audycie manualnym ekspert przechodzi wybrane strony i ścieżki kryterium po kryterium. Korzysta z klawiatury, powiększenia, czytników ekranu i narzędzi deweloperskich, ale przede wszystkim ocenia sens: czy opis obrazu oddaje jego treść, czy komunikat błędu mówi, co poprawić, czy kolejność czytania jest logiczna.
To metoda wolniejsza i droższa, a jej jakość zależy od doświadczenia audytora. Obejmuje za to obszary, których żaden automat nie rozstrzygnie. Cały proces – od próbki stron po retest – opisujemy w tekście o tym, jak przebiega audyt WCAG.
Automatyczny test WCAG a audyt manualny w praktyce
Różnicę najlepiej widać na konkretnych przypadkach. Automat zwykle wykrywa brak czegoś, ale nie ocenia jakości tego, co już jest.
| Obszar i kryterium | Automat wykryje | Człowiek musi ocenić |
|---|---|---|
| Teksty alternatywne: 1.1.1 Non-text Content – treść nietekstowa | Obraz bez atrybutu alt, link-obrazek bez nazwy | Czy opis oddaje treść lub funkcję obrazu i czy obraz dekoracyjny ma pusty alt="" |
| Kontrast: 1.4.3 Contrast (Minimum) – kontrast minimalny | Tekst na jednolitym tle poniżej progu, np. #999999 na białym (ok. 2,85:1 przy wymaganych 4,5:1) | Tekst na zdjęciu, gradiencie lub w grafice oraz kontrast w stanach najechania i fokusu |
| Formularze: 3.3.2 Labels or Instructions – etykiety lub instrukcje | Pole bez etykiety ani innej nazwy dostępnej | Czy etykieta i instrukcje są zrozumiałe, a wymagany format danych opisany przed wysłaniem |
| Klawiatura i fokus: 2.1.1 Keyboard – obsługa klawiaturą; 2.4.3 Focus Order – kolejność fokusu; 2.4.7 Focus Visible – widoczny fokus | Wybrane sygnały, np. dodatni tabindex albo przewijany obszar niedostępny z klawiatury | Czy wszystko działa bez myszy, czy kolejność fokusu jest logiczna, czy fokus jest widoczny i czy nie ma pułapki klawiaturowej |
| Komunikaty dynamiczne: 4.1.3 Status Messages – komunikaty o stanie | Błędy w atrybutach ARIA, np. nieprawidłowa rola lub wartość | Czy czytnik ekranu ogłosi „Dodano do koszyka”, błąd walidacji albo liczbę wyników filtrowania |
| Multimedia: 1.2.2 Captions (Prerecorded) – napisy do nagrań | Najwyżej brak ścieżki napisów w elemencie <video> | Czy napisy są w osadzonym odtwarzaczu, zsynchronizowane i poprawne oraz czy ruchome treści da się zatrzymać (2.2.2 Pause, Stop, Hide – pauza, zatrzymanie, ukrycie) |
| Struktura: 1.3.1 Info and Relationships – informacje i relacje | Puste nagłówki, tabele danych bez nagłówków, błędnie zbudowane listy | Czy to, co wygląda jak nagłówek, jest nim w kodzie i czy nagłówki opisują treść |
Oto fragment, który może przejść test automatyczny bez ani jednego błędu, a mimo to nie pomoże nikomu, kto korzysta z czytnika ekranu:
<img src="kurtka-zimowa.jpg" alt="IMG_2034">
<label for="pole1">Pole 1</label>
<input id="pole1" type="text">
<a href="/regulamin">Kliknij tutaj</a>Obraz ma alt, pole ma etykietę, link ma tekst – formalnie wszystko jest na miejscu. Niektóre narzędzia oznaczą podejrzany opis jako element do sprawdzenia, ale to, że żaden z tych tekstów nic nie mówi, oceni dopiero człowiek.
Ile problemów wykrywają automaty?
Najczęściej przywoływana liczba pochodzi z badania Deque z 2021 r.: na podstawie danych z audytów automatyczne testy axe-core wykryły ok. 57% problemów dostępności. Liczono je jednak według liczby wystąpień. Błędy masowe, jak brak opisu na setkach zdjęć produktów, łatwo wykryć, a występują bardzo często, więc podnoszą ten odsetek.
Inne badania, liczące np. według kryteriów WCAG, podają inne wartości, ale wniosek jest wspólny: automat wykrywa tylko część problemów. Niektórych kryteriów nie da się rozstrzygnąć maszynowo wcale – np. tego, czy komunikat błędu podpowiada, jak go poprawić (3.3.3 Error Suggestion – sugestie korekty błędów). W3C pisze wprost, że narzędzia nie określają dostępności, a jedynie pomagają ją ocenić.
Nie znaczy to, że automat jest mało przydatny. Według raportu WebAIM Million 2025 ok. 95% stron głównych miliona popularnych witryn miało automatycznie wykryte błędy WCAG 2. Najprostsze problemy wciąż są powszechne, a automat znajduje je najtaniej.
Zero błędów w teście automatycznym nie oznacza dostępnej strony. Oznacza tylko, że nie znaleziono problemów, które automat potrafi wykryć.
Fałszywe alarmy i elementy „do weryfikacji”
Wynik automatu nie jest zero-jedynkowy. Oprócz jednoznacznych błędów narzędzia zgłaszają elementy, których nie potrafią rozstrzygnąć, np. kontrast tekstu na zdjęciu. Takie pozycje nie są ani błędem, ani zaliczeniem – trzeba je sprawdzić ręcznie. W Raporcie Podstawowym Cyfrowo Dostępni trafiają one na osobną listę elementów do ręcznej weryfikacji.
Zdarzają się też fałszywe alarmy – np. gdy narzędzie źle odczyta tło złożone z kilku warstw albo zgłosi niski kontrast tekstu w logotypie, który jest z tego wymagania wyłączony. Częstszy kłopot jest odwrotny: problemy, których automat w ogóle nie zauważy, jak alt="zdjęcie" albo mylący opis linku.
Każdą pozycję z raportu potwierdź i przypisz do osoby albo oznacz jako fałszywy alarm z krótkim uzasadnieniem. I nie naprawiaj „pod narzędzie”: dopisanie alt="obraz" uciszy ostrzeżenie, ale nikomu nie pomoże.
Jak łączyć obie metody w jednym procesie
Najlepiej działa podział pracy: automat stale pilnuje powtarzalnych błędów, a człowiek okresowo ocenia to, co najważniejsze dla użytkowników.
- Automat w procesie wytwarzania. Reguły axe-core w testach end-to-end i w CI zatrzymują regresje, zanim trafią na produkcję.
- Regularny skan całego serwisu. Po większych wdrożeniach i cyklicznie, bo błędy wprowadza też redakcja, np. dodając zdjęcia bez opisu.
- Audyt ekspercki kluczowych ścieżek. Przed premierą, po redesignie i przy nowych procesach, takich jak zakup, rejestracja czy logowanie.
- Szybkie kontrole ręczne w zespole. Każda nowa funkcja przechodzi test klawiaturą i czytnikiem ekranu; pomoże w tym instrukcja, jak sprawdzić stronę pod kątem WCAG.
- Testy z użytkownikami. Dla najważniejszych procesów – pokażą problemy, których nie opisuje żadne kryterium.
Automatyczny test WCAG a audyt manualny: co wybrać w Twojej sytuacji
Mała firma ze stroną wizytówką
Zacznij od testu automatycznego i poprawek w motywie, a potem sam sprawdź klawiaturą menu i formularz kontaktowy. Audyt ekspercki rozważ przy redesignie albo wtedy, gdy strona obsługuje ważny proces, np. rezerwacje.
Sklep internetowy
Regularnie skanuj główne szablony: kategorię, kartę produktu, koszyk i zamówienie. Całą ścieżkę zakupu – z płatnością, komunikatami błędów i banerem cookies – zleć do audytu eksperckiego i zaplanuj retest. Listę kontrolną znajdziesz w artykule o dostępności sklepu internetowego.
Agencja lub software house
Wbuduj automat w CI i w checklistę odbioru projektu, a przed oddaniem strony klientowi dołóż ręczną kontrolę kluczowych szablonów. Przy projektach z rozbudowanymi procesami zaproponuj audyt ekspercki jako osobny etap. Jak wykorzystać raporty w pracy z klientami, opisujemy na stronie dla agencji.
Najczęstsze pytania
Czy rozszerzenia do przeglądarki wystarczą do testowania WCAG?
To wygodne narzędzia do szybkiej kontroli pojedynczej strony podczas pracy. Mają jednak te same ograniczenia co każdy test automatyczny: sprawdzają kod, a nie to, czy stroną da się wygodnie posłużyć.
Czy sztuczna inteligencja zastąpi audyt manualny?
Narzędzia z elementami AI mogą podpowiadać np. treść tekstu alternatywnego albo wskazywać podejrzane miejsca, ale ich wyniki nadal trzeba zweryfikować. Żadne narzędzie samodzielnie nie potwierdzi zgodności strony z WCAG.
Kto może przeprowadzić audyt manualny?
Osoba, która dobrze zna WCAG i techniki dostępności oraz sprawnie korzysta z technologii asystujących, np. czytników ekranu. Zapytaj wykonawcę o doświadczenie i poproś o fragment przykładowego raportu.
Czy audyt manualny obejmuje treści i dokumenty?
Tak, jeśli zostały ujęte w zakresie: ekspert może ocenić np. zrozumiałość instrukcji, sens tekstów alternatywnych czy dostępność dokumentów PDF. Przy zamawianiu audytu wskaż więc, które treści i pliki mają zostać sprawdzone.