Jak testować stronę według WCAG, krok po kroku

Testowanie strony według WCAG oznacza sprawdzenie jej pod kątem kryteriów sukcesu Wytycznych dotyczących dostępności treści internetowych, zwykle na poziomie AA. Żadne pojedyncze narzędzie nie zrobi tego w całości. Wiarygodny test łączy automatyczne skanowanie z testami ręcznymi, w których człowiek korzysta z klawiatury, powiększenia przeglądarki i czytnika ekranu. Poniżej procedura, którą polecamy sklepom, serwisom usługowym i agencjom – w kolejności, która przy najmniejszym wysiłku znajduje najwięcej problemów.

To ogólne informacje, a nie porada prawna. Nasze własne testy to automatyczna kontrola, a nie pełny audyt.

Krok 0: wybór stron do testu (próbka)

Rzadko testuje się każdą stronę. Metodologia oceny zgodności stron internetowych W3C (WCAG-EM) opisuje pięć kroków: określenie zakresu, poznanie serwisu, wybór reprezentatywnej próbki, ocenę próbki i raport z wynikami. Próbka łączy próbkę strukturalną z kilkoma losowo wybranymi stronami.

W sklepie internetowym próbka strukturalna zwykle obejmuje:

• stronę główną, stronę kategorii, kartę produktu, wyniki wyszukiwania;
• każdy krok zamówienia, od koszyka do potwierdzenia, ponieważ WCAG wymaga, aby kompletne procesy spełniały wymagania;
• logowanie, rejestrację, reset hasła i konto klienta;
• formularz kontaktowy, pomoc i stronę z informacją o dostępności;
• strony ze szczególnymi treściami: wideo, mapy, konfiguratory, pliki PDF do pobrania.

Warto zapisać wersję i poziom WCAG (np. WCAG 2.2 AA), używane przeglądarki i technologie wspomagające oraz datę. Przydadzą się do informacji o dostępności.

Krok 1: test automatyczny

Proszę zacząć od narzędzia automatycznego. Jest szybkie, powtarzalne i dobrze radzi sobie z problemami na poziomie kodu: brakiem tekstu alternatywnego, niskim kontrastem tekstu, polami formularzy bez etykiet, przyciskami i linkami bez nazw, brakiem języka strony, błędnym ARIA i małymi celami dotyku.

• Jedną stronę można sprawdzić bezpłatnie naszym WCAG checkerem, a wszystkie strony serwisu – w ramach planu Pandus.
• Strony po zalogowaniu, koszyk i zamówienie sprawdzi nasze rozszerzenie do przeglądarki.
• Inne narzędzia porównuje strona narzędzia do testowania dostępności.

Najpierw warto naprawić znaleziska automatyczne. Zwykle są to problemy szablonów: jedna poprawka w motywie usuwa ten sam błąd na setkach stron. Potem przychodzi czas na kroki ręczne, bo badania różnią się w ocenie, jaką część problemów wykrywa automat, ale zgadzają się, że nie wszystkie.

Krok 2: test klawiaturą

Proszę odłożyć mysz i używać wyłącznie klawiatury:

Należy sprawdzić, czy:

1. Wszystko działa z klawiatury – menu, filtry, opcje produktu, dodawanie do koszyka, zamówienie, baner cookies (2.1.1).
2. Fokus nigdy nie utyka w wyskakującym okienku, widżecie czatu ani osadzonym odtwarzaczu (2.1.2).
3. Fokus jest zawsze widoczny (2.4.7) i nie jest zasłonięty przez przyklejone nagłówki czy banery (2.4.11).
4. Kolejność ma sens i odpowiada kolejności wizualnej (2.4.3).
5. Link „przejdź do treści” lub punkty orientacyjne pozwalają ominąć menu (2.4.1).
6. Okna dialogowe przenoszą fokus do środka po otwarciu i z powrotem po zamknięciu.

Krok 3: powiększenie, dopasowanie i odstępy w tekście

1. Powiększyć przeglądarkę do 200%: żaden tekst nie jest ucięty, nic na siebie nie nachodzi, wszystko nadal działa (1.4.4).
2. Powiększyć do 400% lub zwęzić okno do 320 pikseli CSS: tekst się zawija, czytanie nie wymaga przewijania w poziomie (1.4.10).
3. Zastosować większe odstępy w tekście: nic nie zostaje ucięte (1.4.12).
4. Obrócić telefon: strona działa w orientacji pionowej i poziomej.

Więcej o rozmiarach: WCAG a rozmiar czcionki.

Krok 4: test z czytnikiem ekranu

Czytnik ekranu pokazuje, czy strona ma sens bez patrzenia na nią. Warto użyć co najmniej jednego zestawu na komputerze i jednego na telefonie:

• NVDA (bezpłatny, Windows) z Firefoksem lub Chrome;
• VoiceOver (wbudowany w macOS i iOS) z Safari;
• TalkBack (wbudowany w Androida) z Chrome.

Należy zwrócić uwagę na:

• sensowny tytuł strony i strukturę nagłówków, po której można przeskakiwać (1.3.1);
• opisy obrazów, które mówią to, co ważne (1.1.1);
• przyciski i linki, które mówią, co robią – „Dodaj do koszyka”, a nie „Przycisk” (4.1.2);
• komunikaty o stanie, np. „Dodano do koszyka” lub „3 wyniki”, odczytywane bez przenoszenia fokusu;
• etykiety pól, pola wymagane i błędy odczytywane razem z polem.

Najpierw warto poznać podstawowe polecenia: następny nagłówek, następny link, następne pole formularza, czytaj wszystko. Użytkownicy czytników ekranu poruszają się właśnie w ten sposób, a nie wiersz po wierszu.

Krok 5: formularze i zamówienie

Warto przejść każdy formularz i celowo popełnić błędy:

• każde pole ma widoczną etykietę, nie tylko placeholder;
• błędy są opisane tekstem przy polu, ze wskazówką, jak je poprawić (3.3.1);
• dane już wpisane nie są wymagane ponownie (3.3.7);
• logowanie pozwala na menedżery haseł i wklejanie, a zagadki mają alternatywę (3.3.8);
• atrybuty autocomplete dla imienia, e-maila, adresu i telefonu są ustawione;
• limity czasu można wydłużyć, a zamówienie można sprawdzić przed wysłaniem.

Krok 6: multimedia, kolor i ruch

• Filmy mają napisy (1.2.2); treści tylko audio mają transkrypcję.
• Nic nie odtwarza dźwięku automatycznie dłużej niż przez trzy sekundy bez możliwości zatrzymania.
• Karuzele i animacje można zatrzymać.
• Kolor nie jest jedynym sygnałem błędów, dostępności produktu czy linków w tekście.
• Tekst i elementy sterujące mają wystarczający kontrast; niejasne przypadki można sprawdzić narzędziem do sprawdzania kontrastu.

Krok 7: zapis wyników i ponowny test

Każdy problem warto zapisać ze stroną, elementem, kryterium WCAG, zrzutem ekranu i wagą. Naprawiać według wpływu: najpierw to, co blokuje zakup lub logowanie. Test należy powtarzać po każdym wydaniu, aktualizacji motywu czy nowej aplikacji – regresje dostępności po zmianach są częste. Cotygodniowy monitoring wyłapuje ich część automatyczną.

Kiedy zlecić audyt dostępności

Własne testy to dobra rutyna, ale nie audyt. Profesjonalny audyt dostępności warto rozważyć, gdy potrzebna jest deklaracja zgodności, przed startem lub przetargiem publicznym, po skardze lub piśmie z żądaniem albo gdy wyniki są niejasne. Audytor ręcznie sprawdza wszystkie kryteria danego poziomu, z kilkoma technologiami wspomagającymi, i dokumentuje metodę.

Najczęstsze pytania

Na czym polega test WCAG?

Na sprawdzeniu strony według kryteriów sukcesu Wytycznych dotyczących dostępności treści internetowych. Łączy testy automatyczne, które szybko znajdują problemy w kodzie, z testami ręcznymi wykonywanymi przez człowieka z klawiaturą, powiększeniem i czytnikiem ekranu.

Czy test WCAG można w pełni zautomatyzować?

Nie. Narzędzia automatyczne znajdują tylko część problemów. To, czy tekst alternatywny ma sens, czy kolejność fokusu jest logiczna i czy komunikat o błędzie jest zrozumiały, musi ocenić człowiek.

Jak sprawdzić obsługę klawiaturą?

Odłożyć mysz. Poruszać się klawiszami Tab i Shift+Tab, uruchamiać linki klawiszem Enter, a przyciski klawiszem Enter lub spacją, w menu używać strzałek, a okna dialogowe zamykać klawiszem Esc. Fokus powinien być zawsze widoczny, przechodzić w logicznej kolejności i nigdzie nie utknąć.

Z jakim czytnikiem ekranu testować?

Z NVDA i przeglądarką Firefox lub Chrome w systemie Windows, z VoiceOver i Safari w macOS i iOS oraz z TalkBack i Chrome w Androidzie. Test z jednym czytnikiem na komputerze i jednym na telefonie znajduje większość problemów.

Ile stron trzeba przetestować?

Reprezentatywną próbkę, tak jak opisuje to metodologia W3C WCAG-EM: stronę główną, po jednej stronie każdego szablonu, wszystkie kroki kluczowych procesów, takich jak zamówienie i logowanie, oraz kilka losowych stron.

Kiedy potrzebny jest profesjonalny audyt dostępności?

Gdy potrzebna jest deklaracja zgodności, przed publicznym startem lub przetargiem, po skardze lub piśmie z żądaniem albo gdy własne testy zostawiają otwarte pytania. Audyt obejmuje ręcznie wszystkie kryteria; automatyczna kontrola – nie.

Źródła

• W3C, WCAG-EM overview: https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/
• W3C, Easy Checks – pierwszy przegląd dostępności strony: https://www.w3.org/WAI/test-evaluate/preliminary/
• W3C, WCAG 2.2: https://www.w3.org/TR/WCAG22/