Audyt zgodności strony z WCAG 2.2 to proces łączący badania techniczne, ocenę użyteczności i sprawdzone metody raportowania. Celem jest określenie, w jakim stopniu serwis spełnia wymogi dostępności dla osób korzystających z różnych urządzeń i technologii wspomagających. Poniżej znajdziesz praktyczny opis etapów audytu, metodykę testów oraz rekomendacje pozwalające przeprowadzić rzetelną ocenę i zaplanować wdrożenie poprawek.

Znaczenie i zakres norm WCAG 2.2

Standardy WCAG 2.2 określają kryteria, które pomagają projektować treści webowe dostępne dla jak najszerszej grupy osób, w tym użytkowników z niepełnosprawnościami wzroku, słuchu, mobilności czy poznawczymi. Zrozumienie poziomów zgodności (A, AA, AAA) i priorytetów biznesowych jest kluczowe przed rozpoczęciem audytu.

• dostępność jest nie tylko wymogiem prawnym w wielu jurysdykcjach, ale także elementem dobrej praktyki UX.
• Wybór poziomu docelowego (najczęściej AA) determinuje zakres testów i wymaganych poprawek.
• WCAG 2.2 wprowadza dodatkowe kryteria dotyczące m.in. nawigacji i interakcji mobilnych — warto zapoznać się z nowymi wytycznymi przed audytem.

Przygotowanie do audytu: planowanie i zbieranie danych

Solidne przygotowanie minimalizuje ryzyko pominięcia istotnych elementów. Etap przygotowawczy obejmuje wyznaczenie zakresu, ustalenie kryteriów sukcesu oraz zebranie informacji o technologii i użytkownikach.

• Określenie zakresu: czy audyt obejmuje cały serwis, wybrane sekcje, aplikację SPA czy wersję mobilną?
• Zebranie dokumentacji technicznej: schematy, listy stron, sitemap, technologie front-endowe, używane biblioteki JS i ARIA.
• Identyfikacja kluczowych stron i ścieżek użytkownika (np. logowanie, koszyk, formularze), które mają największy wpływ na cele biznesowe.
• Utworzenie profili użytkowników, w tym przedstawicieli osób korzystających z czytników ekranu, powiększeń ekranu i klawiatury.
• Ustalenie poziomu zgodności docelowego (np. AA) i szczególnych priorytetów.

Metodyka audytu: narzędzia automatyczne i testy manualne

Audyt powinien łączyć testy automatyczne z manualnymi oraz testami z udziałem użytkowników. Automaty pomagają wykryć oczywiste problemy, ale nie zastąpią oceny jakościowej.

Testy automatyczne

• Narzędzia takie jak Axe, Lighthouse, WAVE czy Pa11y szybko analizują kod i wskazują błędy: brakujące etykiety, problemy z kontrastem, nieprawidłowe role ARIA.
• Automaty sprawdzają statyczne aspekty, ale generują wiele fałszywych alarmów — każdy wynik musi być ręcznie zweryfikowany.

Testy manualne

• Sprawdzenie działania nawigacji klawiaturowej (tab, shift+tab, enter, spacja). Użytkownicy często poruszają się klawiatura zamiast myszy.
• Weryfikacja kolejności fokusów i widoczności wskaźnika fokusu. Brak wyraźnego fokusu uniemożliwia interakcję nawigacja w serwisie.
• Ocena semantyki HTML: odpowiednie znaczniki nagłówków, role ARIA tylko tam, gdzie to konieczne, prawidłowe użycie elementów form (semantyka wpływa na czytniki ekranu).
• Kontrola etykiet i powiązań atrybut alt w obrazach, podpisy i transkrypcje w materiałach multimedialnych.
• Testy z czytnikiem ekranu (NVDA, VoiceOver) — czy treść jest logicznie czytana i czytelnicy mogą wykonywać interakcje.
• Symulacje zaburzeń widzenia: powiększenie, wysoka rozdzielczość, symulacja daltonizmu oraz testy kontrastu (kontrast tekstu i elementów interfejsu).

Testy z udziałem użytkowników i scenariusze testowe

Ocena z prawdziwymi użytkownikami z doświadczeniem w używaniu technologii wspomagających dostarcza informacji, których nie wykryją narzędzia automatyczne. Badania z użytkownikami powinny obejmować realistyczne scenariusze.

• Rekrutacja testerów z różnymi potrzebami (osoby niewidome, niedowidzące, z ograniczoną sprawnością ręki, zaburzeniami poznawczymi).
• Przygotowanie scenariuszy: realizacja zamówienia, wypełnienie formularza kontaktowego, odnalezienie informacji, rejestracja konta.
• Moderowane sesje testowe i obserwacja: notowanie punktów blokujących i momentów niepewności.
• Zbieranie danych jakościowych (opisy trudności) oraz ilościowych (czas wykonania zadania, liczba błędów).

Lista kontrolna kluczowych kryteriów WCAG do sprawdzenia

Poniższa lista stanowi listę kontrolną najczęściej występujących obszarów do audytu. Warto ją wykorzystać jako podstawę do zorganizowania testów.

• Tekst alternatywny dla obrazów i ikon — obecność i poprawność atrybut alt.
• Kontrast kolorów — minimalne współczynniki dla tekstu i elementów interfejsu (kontrast min. 4.5:1 dla normalnego tekstu przy poziomie AA).
• Semantyczna struktura dokumentu: nagłówki, listy, sekcje (semantyka).
• Dostępność formularzy: etykiety, błędy, instrukcje i powiązania label/input.
• Możliwość nawigacji przy użyciu klawiatury (klawiatura i nawigacja).
• Widoczny i logiczny fokus.
• Teksty alternatywne dla multimediów: napisy, transkrypcje, audiodeskrypcja.
• Unikanie migających treści i elementów wywołujących napady (kryteria dotyczące sekwencji obrazów).
• Poprawne użycie ARIA: minimalizowanie nieprawidłowych ról/atrybutów, stosowanie ARIA w sposób kompatybilny z natywnymi kontrolkami.
• Dostosowanie do urządzeń mobilnych: dotykowe elementy muszą mieć odpowiedni rozmiar, a interakcje dotykowe nie mogą być utrudnione.

Narzędzia i techniki wspomagające audyt

Wybór narzędzi zależy od skali audytu i budżetu. Poniżej lista popularnych narzędzi i krótkie wskazówki ich zastosowania.

• Axe (wtyczki do przeglądarek) — szybka automatyczna analiza i szczegółowe reguły naprawcze.
• Lighthouse — integracja z Chrome, ocena dostępności i wydajności.
• WAVE — wizualne oznaczanie problemów na stronie, dobre do prezentacji wyników klientowi.
• NVDA, VoiceOver — testowanie interakcji z czytnikami ekranu (NVDA darmowy na Windows, VoiceOver w macOS/iOS).
• Color Contrast Analyzers — narzędzia do pomiaru kontrastu i symulacji zaburzeń percepcji kolorów.
• Keyboard testing — proste, manualne sprawdzenie działania bez myszy.
• Narzędzia do testów kompatybilności ARIA i sprawdzania DOM (DevTools, accessibility tree).

Tworzenie raportu z audytu i priorytetyzacja napraw

Dobry raport to nie tylko lista błędów, ale też kontekst, ocena wpływu na użytkownika i plan działań naprawczych. Raport musi być czytelny dla zespołu developerskiego i decydentów.

• Struktura raportu: streszczenie, metodyka, zakres testów, wykryte problemy pogrupowane wg priorytetów (krytyczne, wysokie, średnie, niskie).
• Dla każdego problemu zamieść: opis, lokalizacja (URL, selektor), kryterium WCAG, wpływ na użytkownika, kroki reprodukcji, rekomendowane rozwiązanie i szacunkowy koszt naprawy.
• Dodaj przykłady kodu poprawnego i niepoprawnego, zrzuty ekranu lub nagrania wideo ilustrujące problem.
• Sugeruj harmonogram wdrożenia i mierniki sukcesu (np. liczba krytycznych błędów do usunięcia w ciągu 2 sprintów).

Praktyczne wskazówki dla zespołu developerskiego

Współpraca między audytorem a zespołem technicznym zwiększa skuteczność poprawek. Poniżej kilka praktycznych porad.

• Włącz testy dostępności do procesu CI/CD — automatyczne skanery pomagają wychwycić regresje.
• Szkolenia dla developerów i projektantów: podstawy dostępność i dobre praktyki semantycznego HTML.
• Wykorzystanie komponentów bibliotecznych, które są już dostępne i przetestowane pod kątem dostępności.
• Preferowanie natywnych elementów HTML zamiast budowania kontrolek od zera — natywne kontrolki mają domyślną obsługę przez technologie wspomagające.
• Implementacja backlogu z zadaniami dostępnosiowymi w małych iteracjach z jasną definicją gotowości.

Monitorowanie i utrzymanie zgodności

Dostępność nie jest jednorazowym projektem — wymaga stałego monitoringu. Wprowadź procesy, które utrzymają zgodność w czasie.

• Regularne przeglądy (np. kwartalne) i automatyczne testy przy każdym wdrożeniu.
• Feedback od użytkowników jako źródło informacji o problemach, których nie wykryją narzędzia.
• Aktualizacja dokumentacji projektowej i stylów — wzorce dostępności powinny być częścią design systemu.
• Raportowanie metryk dostępności do interesariuszy: liczba naprawionych błędów, wyniki testów użytkowników, poziom zgodności z WCAG.

• Łącz automatyczne i manualne metody — tylko w ten sposób zidentyfikujesz większość problemów.
• Testuj z prawdziwymi użytkownikami — oni pokażą, jak funkcje sprawdzają się w realnym użyciu.
• Priorytetyzuj błędy według wpływu na użytkownicy — krytyczne bariery naprawiaj najpierw.
• Traktuj dostępność jako element jakości produktu, nie jedynie jako listę kontrolną do odhaczenia.