Test WCAG online: co sprawdza skaner i jak czytać jego wynik

Test WCAG online to najprostszy sposób, żeby sprawdzić, jakie problemy z dostępnością cyfrową ma kod Twojej strony. Skaner szybko przejrzy setki elementów i wskaże brakujące teksty alternatywne, pola bez etykiet czy zbyt słaby kontrast.

Wynik łatwo jednak przecenić albo źle odczytać. Wyjaśniamy, co automat naprawdę sprawdza, czego nie oceni i jak zamienić raport w plan poprawek.

Co sprawdza automatyczny test WCAG

Skaner porównuje kod strony z zestawem reguł. Każda reguła opisuje warunek, który da się sprawdzić maszynowo, np. „każdy obraz ma tekst alternatywny” albo „tekst ma kontrast co najmniej 4,5:1”. Większość reguł jest przypisana do konkretnych kryteriów WCAG na poziomach A i AA – pełną listę kryteriów zawiera specyfikacja WCAG 2.2.

Typowy skaner WCAG sprawdza przede wszystkim:

• alternatywy tekstowe – czy obrazy i przyciski graficzne mają tekst alternatywny (1.1.1 Non-text Content – treść nietekstowa);
• kontrast tekstu – liczony z kolorów tekstu i tła tam, gdzie da się je jednoznacznie ustalić (1.4.3 Contrast (Minimum) – kontrast minimalny);
• nazwy elementów interaktywnych – czy linki, przyciski i pola mają nazwę, którą odczyta czytnik ekranu (4.1.2 Name, Role, Value – nazwa, rola, wartość);
• etykiety formularzy – czy pole jest w kodzie powiązane z etykietą (3.3.2 Labels or Instructions – etykiety lub instrukcje);
• język i tytuł strony – atrybut lang i niepusty element title (3.1.1 Language of Page – język strony; 2.4.2 Page Titled – tytuł strony);
• poprawność ARIA – dozwolone role, wymagane atrybuty i odwołania do istniejących elementów;
• strukturę – poprawnie zbudowane listy i tabele (1.3.1 Info and Relationships – informacje i relacje);
• blokadę powiększania – np. user-scalable=no w znaczniku meta viewport (1.4.4 Resize Text – zmiana rozmiaru tekstu).

Takie błędy zwykle powtarzają się w szablonach, więc ich usunięcie szybko porządkuje całą witrynę. Przykłady poprawek znajdziesz w artykule o najczęstszych błędach WCAG.

Czego automatyczny test nie sprawdzi

Automat sprawdza, czy coś istnieje i ma poprawną formę. Nie ocenia, czy ma sens ani czy działa tak, jak powinno. Taki element zwykle przejdzie skan bez żadnego błędu:

<!-- wygląda jak przycisk, ale działa tylko po kliknięciu myszą -->
<div class="btn" onclick="dodajDoKoszyka()">Dodaj do koszyka</div>

Ma czytelny tekst, a skaner nie wie, że element reaguje na kliknięcie. Tymczasem nie da się do niego przejść klawiszem Tab ani uruchomić go klawiaturą, a czytnik ekranu nie ogłosi go jako przycisku. Poza zasięgiem automatu są przede wszystkim:

• sens treści – czy alt, nazwa linku albo nagłówek opisują to, co trzeba (więcej w artykule o tekście alternatywnym);
• logika interfejsu – czy kolejność fokusu jest sensowna (2.4.3 Focus Order – kolejność fokusu) i czy komunikaty pojawiają się we właściwym miejscu;
• pełna obsługa klawiaturą – czy każdą funkcję da się wykonać bez myszy (2.1.1 Keyboard – obsługa klawiaturą) i czy fokus nie utknie w oknie dialogowym (2.1.2 No Keyboard Trap – brak pułapki klawiaturowej);
• zrozumiałość – czy instrukcje są jasne, a komunikat o błędzie mówi, co jest nie tak (3.3.1 Error Identification – identyfikacja błędów);
• multimedia – czy film ma napisy i czy są one poprawne (1.2.2 Captions (Prerecorded) – napisy do nagrań);
• praca z technologiami asystującymi – czy z czytnikiem ekranu da się wykonać całe zadanie, np. złożyć zamówienie.

Według analizy Deque z 2021 roku (dane z audytów) testy axe-core wykryły ok. 57% problemów, licząc według liczby wystąpień. Inne badania podają inne wartości, ale wniosek jest wspólny: automat znajduje tylko część problemów. Skąd te różnice i jak łączyć metody, wyjaśnia artykuł automatyczny test WCAG a audyt manualny.

Jak działa skan w przeglądarce: renderowanie, JavaScript, stany

Najprostsze narzędzia pobierają sam kod HTML wysłany przez serwer. To szybkie, ale pomija wszystko, co dopisuje JavaScript: menu budowane skryptem, produkty doładowywane w tle czy aplikacje w React lub Vue. Taki test nie zna też ostatecznych kolorów, więc nie policzy wiarygodnie kontrastu.

Skaner działający w przeglądarce najpierw otwiera stronę jak zwykły odwiedzający: pobiera style, uruchamia skrypty i czeka na załadowanie treści. Dopiero wtedy sprawdza reguły na gotowym drzewie dokumentu (DOM), z wyliczonymi kolorami, widocznością i nazwami elementów. Widzi więc stronę tak jak użytkownik – ale tylko w jednym momencie.

To ważne ograniczenie, bo skan ocenia zwykle:

• stan tuż po załadowaniu, w jednym rozmiarze okna;
• zamknięte menu, zwinięte akordeony i ukryte okna dialogowe;
• formularze przed wysłaniem, czyli bez komunikatów o błędach;
• strony publiczne, bez treści dostępnych po zalogowaniu.

Rozwinięte menu mobilne, koszyk po dodaniu produktu czy walidację formularza trzeba więc sprawdzić ręcznie albo testem opartym na scenariuszu.

Bezpłatny skan wstępny na stronie głównej to szybki test pierwszego rodzaju: kilka podstawowych testów kodu HTML jednej wskazanej strony (język, tytuł, teksty alternatywne, nazwy przycisków i linków, etykiety pól) z orientacyjnym wynikiem. Raport Podstawowy za 49 zł bada do 20 podstron w przeglądarce Chromium silnikiem axe-core, według reguł WCAG 2.0, 2.1 i 2.2 na poziomach A i AA – to wciąż test automatyczny, a nie audyt ani certyfikat.

Jak czytać wynik testu WCAG

Raport z testu dostępności strony ma zwykle cztery warstwy opisane niżej. Każdą czyta się trochę inaczej.

Wagi problemów

Waga to ocena narzędzia, jak bardzo błąd może utrudnić korzystanie ze strony. To inna informacja niż poziom WCAG (A, AA), dlatego dobry raport pokazuje obie.

Przykłady są orientacyjne. Każde narzędzie przypisuje wagi po swojemu.

Reguły a wystąpienia

Reguła to rodzaj problemu, np. „przycisk nie ma dostępnej nazwy”. Wystąpienie to każdy konkretny element, który ją narusza. Jedna reguła z 48 wystąpieniami to często jeden błąd w szablonie karty produktu, powielony na liście – i jedna poprawka, która usuwa wszystkie.

Wystąpienie ma zwykle selektor i fragment kodu, dzięki którym programista szybko znajdzie element:

Reguła:   przycisk musi mieć dostępną nazwę (4.1.2)
Waga:     krytyczny
Selektor: .product-card > button.add-to-cart
Kod:      <button class="add-to-cart"><svg …></svg></button>

Dlatego nie porównuj stron po samej liczbie wystąpień. Długa lista produktów podbije licznik, choć błąd jest jeden.

Elementy do ręcznej weryfikacji

Część wyników to nie błędy, tylko przypadki, których automat nie potrafi rozstrzygnąć – np. kontrast tekstu na zdjęciu lub gradiencie, gdzie narzędzie nie zna koloru tła pod każdą literą. Trafiają one na osobną listę i czekają na decyzję człowieka.

Czytaj tę listę tak samo jak błędy: według reguł i komponentów. Jeśli ten sam baner ze zdjęciem wraca na 15 podstronach, wystarczy sprawdzić go raz i zapisać wynik przy komponencie. Nie wliczaj tych pozycji do „zaliczonych” – dopóki nikt ich nie obejrzał, ich status jest nieznany.

Wynik 0–100: wskaźnik ryzyka, nie ocena zgodności

Wynik zbiorczy streszcza liczbę i wagę wykrytych problemów – im wyższy, tym mniej błędów znalazł automat. To wygodny wskaźnik ryzyka i postępu, ale nie ocena zgodności z WCAG ani z przepisami. Nawet 100 punktów oznacza tylko, że reguły automatyczne nie znalazły błędów w zbadanym zakresie.

Porównuj wyniki w czasie: ta sama strona, ten sam zakres, to samo narzędzie. Liczby z różnych skanerów nie są porównywalne, bo każdy ma inne reguły i inny sposób liczenia.

Jak zaplanować poprawki na podstawie wyniku

1. Zacznij od wag krytycznych i poważnych w elementach wspólnych – nagłówku, menu, stopce, szablonach i formularzach. Jedna poprawka komponentu usuwa dziesiątki wystąpień.
2. Grupuj według reguł i odpowiedzialności. Błędy w kodzie szablonu trafiają do programisty, brakujące opisy obrazów czy niejasne linki – do osoby redagującej treści.
3. Uwzględnij kluczowe ścieżki. Błąd w formularzu zamówienia jest pilniejszy niż ten sam błąd na archiwalnym wpisie.
4. Zaplanuj ręczną weryfikację elementów, których automat nie rozstrzygnął, i stanów, których nie widział.
5. Po wdrożeniu powtórz test w tym samym zakresie i porównaj wyniki.

Jak może wyglądać raport z podziałem na reguły, wagi i elementy do weryfikacji, zobaczysz w przykładowym raporcie.

Jak często robić test dostępności strony

Dostępność zmienia się razem ze stroną. Nowa wtyczka, aktualizacja motywu czy baner promocyjny mogą dodać błędy, których wczoraj nie było. Test automatyczny warto więc powtarzać:

• po każdej zmianie szablonu, motywu lub komponentów (menu, formularze, koszyk);
• przed publikacją nowej sekcji lub strony kampanii;
• cyklicznie, np. raz w miesiącu lub raz na kwartał, jeśli treści zmieniają się często;
• po poprawkach – żeby potwierdzić, że błędy zniknęły i nie pojawiły się nowe.

Test można też wpiąć w proces wdrożeniowy, żeby błędy wychodziły na jaw przed publikacją. To, czego automat nie obejmie, sprawdzisz według instrukcji jak sprawdzić stronę pod kątem WCAG.

Najczęstsze pytania

Czy test WCAG online może coś zepsuć na stronie?

Nie. Skaner otwiera strony i odczytuje ich kod tak jak przeglądarka odwiedzającego – nie zmienia treści i nie wysyła formularzy. Obciążenie serwera przypomina wizytę osoby, która przegląda kilka lub kilkanaście podstron.

Czy skaner WCAG sprawdzi strony dostępne dopiero po zalogowaniu?

Testy online zwykle badają tylko strony publiczne. Panel klienta czy konto użytkownika trzeba sprawdzić ręcznie albo narzędziem uruchomionym w zalogowanej sesji, np. rozszerzeniem przeglądarki lub testem w środowisku programistycznym.

Czy baner cookies wpływa na wynik testu?

Może. Jeśli skaner otworzy stronę z widocznym banerem, sprawdzi także jego przyciski, kontrast i nazwy, a znalezione błędy trafią do wyniku. To przydatne, bo baner jest pierwszym elementem, z którym styka się każdy nowy użytkownik.

Czy test WCAG obejmuje pliki PDF i aplikacje mobilne?

Typowy skaner stron bada dokumenty HTML otwierane w przeglądarce. Pliki PDF i natywne aplikacje mobilne wymagają osobnych narzędzi oraz testów ręcznych.