Audyt dostępności strony według WCAG 2.2: co sprawdzić poza kontrastem

Audyt dostępności łatwo zacząć od koloru i zakończyć na wyniku automatycznego skanera. To wygodne, lecz nie wystarcza. Narzędzie może wykryć brak etykiety, niski kontrast albo pusty nagłówek, ale nie oceni wiarygodnie, czy kolejność fokusu ma sens, komunikat błędu pomaga dokończyć formularz ani czy użytkownik czytnika ekranu rozumie zmianę stanu.

WCAG 2.2 jest standardem testowalnych kryteriów, a nie listą dekoracyjnych poprawek. Dla właściciela firmy najważniejsze jest przełożenie go na zadania użytkownika: znalezienie usługi, porównanie opcji, rezerwację, zakup, logowanie i kontakt. Dlatego dobry audyt łączy automat, kontrolę manualną, reprezentatywną próbę stron oraz — gdy stawka to uzasadnia — badanie z osobami korzystającymi z różnych technologii wspomagających.

Ustal zakres, zanim zaczniesz liczyć błędy

Zdanie „strona jest zgodna z WCAG” ma sens tylko z zakresem, wersją standardu, poziomem, datą i metodą oceny. Serwis może się zmieniać codziennie, a jeden sprawdzony adres nie reprezentuje formularza, koszyka i panelu klienta.

Na początku zapisz:

• wersję WCAG i docelowy poziom, np. WCAG 2.2 AA;
• domeny, języki i środowiska objęte przeglądem;
• najważniejsze typy stron i komponentów;
• kluczowe procesy, takie jak kontakt, rezerwacja, płatność i odzyskanie hasła;
• przeglądarki, urządzenia oraz technologie wspomagające użyte w testach;
• ograniczenia próby i elementy wyłączone z zakresu.

Reprezentatywna próba powinna obejmować różne szablony, stany i zadania, nie tylko stronę główną. Formularz z błędem, otwarte menu, modal i wynik wyszukiwania są równie ważne jak stan początkowy.

Cztery warstwy praktycznego audytu

Poniższy model pomaga dobrać metodę do pytania. Warstwy się uzupełniają; wysoki wynik pierwszej nie zastępuje kolejnych.

Automat jest dobrym filtrem regresji. Warto uruchamiać go regularnie, ale wynik procentowy nie jest odsetkiem spełnionych potrzeb użytkowników. Jedna bariera w przycisku płatności może być ważniejsza niż kilkadziesiąt drobnych ostrzeżeń na stronie informacyjnej.

Wstępny raport techniczny uzyskasz przez audyt strony. Następnie wykonaj testy manualne na rzeczywistych zadaniach.

Klawiatura i fokus pokazują strukturę interakcji

Odłóż mysz. Użyj Tab, Shift+Tab, Enter, spacji, strzałek i Escape. Sprawdź, czy wszystkie działania są osiągalne, fokus jest widoczny, kolejność odpowiada układowi i nie powstaje pułapka.

WCAG 2.2 dodało między innymi kryterium 2.4.11 Focus Not Obscured (Minimum) na poziomie AA. Element z fokusem nie powinien zostać całkowicie zasłonięty przez treść autora, np. przyklejony baner albo panel zgody. To praktyczny powód, by testować stronę w ruchu, a nie oglądać statyczny zrzut.

Zapisuj kroki odtworzenia: adres, rozmiar okna, stan komponentu, klawisz i oczekiwany rezultat. „Menu niedostępne” jest słabym zadaniem developerskim. „Po otwarciu menu fokus pozostaje pod warstwą, a Escape go nie zamyka” prowadzi do konkretnej poprawki i testu regresji.

Kontrast jest ważny, ale ma kontekst

Dla zwykłego tekstu WCAG 2.2 wymaga co najmniej 4,5:1 na poziomie AA; dla dużego tekstu co najmniej 3:1. Elementy graficzne potrzebne do rozpoznania komponentu i jego stanu również mają wymagania, z wyjątkami opisanymi w standardzie.

Tester kontrastu pomaga policzyć pojedynczą parę kolorów, a generator dostępnej palety ułatwia zbudowanie skali marki. Sam pomiar dwóch próbek nie obejmuje jednak gradientu, obrazu pod tekstem, przezroczystości, stanów hover, focus, disabled ani kolorów wymuszonych przez system.

Sprawdź także, czy informacja nie opiera się wyłącznie na kolorze. Czerwone obramowanie bez tekstu błędu może być trudne do zauważenia i nie mówi, jak naprawić pole. Wykres powinien rozróżniać serie również etykietą, wzorem albo kształtem.

Powiększenie, reflow i rozmiar celu

Powiększ tekst do 200% i sprawdź widok o szerokości odpowiadającej wąskiemu ekranowi. Treść nie powinna znikać, nakładać się ani wymagać jednoczesnego przewijania w dwóch kierunkach tam, gdzie standard tego nie dopuszcza. Szczególnie często zawodzą nagłówki, tabele, przyklejone paski i formularze w modalach.

WCAG 2.2 wprowadza na poziomie AA kryterium minimalnego rozmiaru celu 2.5.8. Co do zasady cel wskaźnika powinien mieć co najmniej 24 na 24 piksele CSS albo spełnić jeden z wyjątków, np. odpowiedni odstęp. Nie sprowadzaj tego do mechanicznego powiększenia każdej ikony. Liczy się rzeczywisty obszar aktywny, sąsiedztwo innych celów i kontekst komponentu.

Małe ikony usuwania, kropki karuzeli i linki stłoczone w stopce zasługują na test na urządzeniu dotykowym. Błąd może nie blokować myszy, ale powodować kosztowne pomyłki kciukiem.

Formularze sprawdzaj od pustego pola do sukcesu

Formularz jest procesem, nie zestawem etykiet. Przejdź całość klawiaturą i czytnikiem ekranu, jeżeli taki test jest w zakresie. Wyślij puste oraz błędne dane, popraw je i zakończ zadanie.

Sprawdź, czy:

• każde pole ma trwałą, programowo powiązaną nazwę;
• instrukcja pojawia się przed momentem, w którym jest potrzebna;
• format danych nie jest przekazywany wyłącznie przez placeholder;
• błąd wskazuje pole, przyczynę i możliwą poprawkę;
• fokus po wysłaniu trafia do podsumowania lub pierwszego błędu w przewidywalny sposób;
• komunikat sukcesu jest dostępny bez polowania wzrokiem po stronie;
• wklejanie i menedżery haseł nie są bez powodu blokowane.

WCAG 2.2 dodaje kryteria dotyczące powtarzanego wprowadzania danych i dostępnego uwierzytelniania. W praktyce warto sprawdzić, czy proces nie wymaga zapamiętywania lub przepisywania informacji, które system może udostępnić, oraz czy test poznawczy nie jest jedyną drogą logowania bez dopuszczonej alternatywy.

Treść i semantyka muszą wspierać decyzję

Nagłówki powinny opisywać strukturę, a nie służyć wyłącznie do uzyskania większego fontu. Link „dowiedz się więcej” może być zrozumiały w jednym akapicie, lecz lista kilku takich linków traci sens. Tekst alternatywny obrazu zależy od funkcji: dekoracja może mieć pusty alt, wykres potrzebuje przekazania informacji, a zdjęcie produktu — użytecznego rozróżnienia.

Sprawdź język dokumentu i fragmentów w innym języku. Oceń komunikaty przy zmianach dynamicznych: wynik filtrowania, dodanie produktu, stan zapisu i błąd sieci. Sam fakt, że tekst pojawił się na ekranie, nie gwarantuje, że technologia wspomagająca go ogłosiła.

Priorytet napraw wynika z wpływu, nie liczby wystąpień

Nadaj każdemu problemowi trzy wymiary:

1. wpływ na zadanie — blokuje, poważnie utrudnia czy tylko irytuje;
2. zasięg — dotyczy jednego opisu czy wspólnego komponentu na setkach stron;
3. ryzyko zmiany — lokalna poprawka treści czy przebudowa zachowania używanego w wielu miejscach.

Najpierw usuwaj bariery blokujące kluczowe procesy oraz problemy systemowe w design systemie. Łatwe poprawki wykonuj szybko, ale nie pozwól, by duża liczba drobnych sukcesów ukryła niedostępny checkout albo formularz kontaktowy.

Raport powinien zawierać dowód, kryterium, lokalizację, kroki odtworzenia, wpływ na użytkownika, propozycję naprawy i sposób ponownego testu. Po wdrożeniu wykonaj retest; zamknięcie zadania w systemie nie jest dowodem usunięcia bariery.

Jeśli potrzebujesz połączyć audyt z przebudową komponentów i testami regresji, sprawdź usługi projektowe i developerskie. Możesz też opisać kluczowy proces oraz zakres serwisu, aby zacząć od reprezentatywnej próby zamiast obietnicy automatycznego certyfikatu.

Źródła

• W3C WAI: co nowego w WCAG 2.2
• W3C: Web Content Accessibility Guidelines 2.2
• W3C WAI: Easy Checks — wstępny przegląd dostępności
• W3C WAI: udział użytkowników w ocenie dostępności
• W3C WAI: szablon raportu z oceny dostępności