Audyt WCAG to uporządkowane sprawdzenie, czy strona lub aplikacja spełnia kryteria dostępności z wytycznych Web Content Accessibility Guidelines – i w których miejscach osoby z niepełnosprawnościami napotkają bariery. Dobry audyt dostępności strony nie kończy się oceną „zdał / nie zdał”, tylko listą konkretnych problemów, które Twój zespół może zaplanować i naprawić.

Poniżej przejdziesz przez cały proces: od ustalenia zakresu i próbki stron, przez metody badania, po raport, poprawki i retest. Jeśli najbardziej interesuje Cię budżet, przeczytaj, ile kosztuje audyt WCAG i od czego zależy cena.

Czym jest audyt WCAG i po co się go robi

Audyt to ocena ekspercka. Osoba, która zna WCAG i techniki dostępności, sprawdza wybrane strony oraz procesy kryterium po kryterium, wspierając się narzędziami. Szuka odpowiedzi na trzy pytania: co nie działa, kogo to dotyka i jak to naprawić.

Audyt dostępności cyfrowej przydaje się przed publikacją nowego serwisu, po redesignie, przy odbiorze prac od wykonawcy i wtedy, gdy musisz rzetelnie opisać, jak Twoja usługa spełnia wymagania dostępności. Daje też punkt odniesienia – po poprawkach widać, co się zmieniło.

Audyt to nie certyfikat. Oficjalny „certyfikat WCAG” nie istnieje – W3C, autor wytycznych, nie weryfikuje deklaracji zgodności. Wynik audytu opisuje stan zbadanej próbki w konkretnym momencie, a każde wdrożenie może go zmienić.

Zakres: standard, poziom i obszary badania

Najpierw ustalasz, według czego strona będzie oceniana. Celem jest zwykle poziom AA, czyli spełnienie wszystkich kryteriów z poziomów A i AA. Zharmonizowana norma EN 301 549 w wersji 3.2.1 odwołuje się do WCAG 2.1 AA, ale rozsądnie jest od razu badać według WCAG 2.2 – ta wersja jest rekomendacją W3C od 5 października 2023 r.

WCAG 2.2 jest zgodne wstecz: spełniając je, co do zasady spełniasz też WCAG 2.1. Co doszło w nowej wersji, opisujemy w artykule WCAG 2.2 – nowe kryteria i zmiany na stronie. Kryteria z poziomu AAA możesz potraktować jako dodatkowe rekomendacje. Poza standardem zakres powinien określać:

  • domeny i subdomeny (np. sklep, blog, panel klienta) oraz środowisko: produkcja czy wersja testowa;
  • urządzenia i widoki: komputer, telefon, powiększenie tekstu i wąski ekran;
  • przeglądarki i technologie asystujące, z którymi będą prowadzone testy;
  • treści dodatkowe: dokumenty PDF, nagrania wideo, widżety zewnętrznych dostawców (płatności, czat, mapy);
  • aplikacje mobilne – jeśli mają zostać ocenione, bada się je osobno.

Jeśli audyt ma pomóc w przygotowaniu do nowych przepisów, zajrzyj też do artykułu o Europejskim Akcie o Dostępności. Ten tekst nie jest poradą prawną.

Dobór próbki: szablony, ścieżki i stany

W większości serwisów audytor nie sprawdza każdego adresu URL, tylko reprezentatywną próbkę. Takie podejście opisuje metodologia W3C WCAG-EM: najpierw rozpoznanie serwisu, potem próbka dobrana celowo, uzupełniona o kilka stron wybranych losowo, które pokazują, czy próbka dobrze oddaje całość.

Kluczowe jest myślenie szablonami i ścieżkami. Sklep z tysiącami produktów może mieć kilkanaście unikalnych szablonów, a błąd w karcie produktu powtórzy się na każdej z nich. WCAG wymaga też, by proces – np. zakup – spełniał kryteria w całości: jeśli nie spełnia ich jeden krok, nie spełnia ich cały proces.

Dobra próbka zwykle obejmuje:

  • stronę główną i elementy wspólne: nagłówek, menu, stopkę, wyszukiwarkę, baner cookies;
  • po jednym przedstawicielu każdego typu strony: kategorię, kartę produktu lub usługi, artykuł, kontakt;
  • pełne ścieżki: rejestrację, logowanie, koszyk i zamówienie, formularz kontaktowy lub rezerwację;
  • stany, których nie widać od razu: błędy walidacji, okna modalne, rozwinięte menu, komunikaty o sukcesie;
  • komponenty szczególne: slidery, mapy, kalendarze, odtwarzacze wideo, wykresy;
  • wybrane dokumenty do pobrania, jeśli są w zakresie.

Próbkę warto zatwierdzić przed startem prac. Wiesz wtedy dokładnie, co zostanie zbadane, a raport nie sugeruje oceny całego serwisu, jeśli sprawdzono tylko jego część.

Metody badania

Rzetelny audyt łączy kilka metod, bo każda z nich widzi co innego.

Narzędzia automatyczne
Szybko wyłapują powtarzalne błędy w kodzie: brak tekstu alternatywnego, pola bez etykiet, zbyt niski kontrast, puste linki. Wykrywają jednak tylko część problemów – więcej na ten temat w porównaniu testu automatycznego i audytu manualnego.
Przegląd ekspercki
Audytor ręcznie ocenia to, czego automat nie rozstrzygnie: obsługę klawiaturą, kolejność i widoczność fokusu, powiększenie tekstu do 200% i widok przy szerokości 320 px, sens tekstów alternatywnych, komunikaty błędów, strukturę nagłówków.
Technologie asystujące
Kluczowe ścieżki przechodzi się z czytnikami ekranu – np. NVDA lub JAWS w Windows, VoiceOver w macOS i iOS, TalkBack w Androidzie – oraz z programem powiększającym.
Testy z użytkownikami (opcjonalnie)
Osoby z niepełnosprawnościami wykonują na stronie realne zadania. Jak podkreśla W3C, testy z udziałem użytkowników ujawniają problemy użyteczności, których nie wykryje sama ocena zgodności.

Jak przebiega audyt: etapy

  1. Ustalenia. Cel, standard, zakres, termin, osoby kontaktowe i dostępy: konto testowe, środowisko testowe, testowe płatności.
  2. Rozpoznanie serwisu i próbka. Audytor poznaje typy stron i procesy, po czym proponuje próbkę do akceptacji.
  3. Test automatyczny. Szybki przegląd próbki, często także szerszego zakresu, który wyłapuje powtarzalne błędy kodu.
  4. Przegląd ekspercki i testy z technologiami asystującymi. Najbardziej pracochłonny etap: ocena kryterium po kryterium na każdej stronie i w każdym kroku ścieżek.
  5. Testy z użytkownikami – jeśli są w zakresie.
  6. Raport i omówienie. Przekazanie wyników i spotkanie z zespołem, na którym ustalacie priorytety.
  7. Poprawki i retest. Zespół wdraża zmiany, a audytor sprawdza, czy problemy zniknęły.

Co powinien zawierać raport z audytu WCAG

Raport ma być narzędziem pracy, a nie dokumentem do szuflady. Zaczyna się od podsumowania: zakres, standard, data, próbka, metody i najważniejsze bariery. Dalej jest szczegółowa lista problemów, w której każda pozycja powinna mieć:

  • opis i wpływ na użytkownika – kto i w jakiej sytuacji napotka barierę;
  • kryterium WCAG z numerem i nazwą;
  • lokalizację: adres strony, krok ścieżki, element lub selektor CSS;
  • wagę lub priorytet;
  • rekomendację naprawy, najlepiej z przykładem kodu;
  • zrzut ekranu lub fragment kodu, który pozwala odtworzyć problem;
  • status uzupełniany po reteście.

Dobry raport oddziela też problemy w komponentach wspólnych (menu, stopka, szablon formularza) od błędów lokalnych. Pojedynczy wpis może wyglądać tak:

Problem
Pole na adres e-mail w kroku 2 zamówienia ma obok tylko tekst „E-mail”, niepowiązany z polem. Czytnik ekranu może ogłosić samo „pole edycji”, bez informacji, co wpisać.
Kryterium
1.3.1 Info and Relationships – informacje i relacje; 4.1.2 Name, Role, Value – nazwa, rola, wartość.
Lokalizacja
/zamowienie, krok 2, selektor #billing-email, zrzut ekranu nr 14.
Waga
Wysoka – utrudnia złożenie zamówienia.
Rekomendacja
Zamień tekst na etykietę powiązaną z polem; atrybut autocomplete dodatkowo ułatwi wypełnianie: 
<label for="billing-email">Adres e-mail</label>
<input id="billing-email" name="email" type="email" autocomplete="email">

Unikaj raportów, które wymieniają tylko niespełnione kryteria, bez lokalizacji i wskazówek. Zespół straci wtedy mnóstwo czasu na ustalanie, czego dotyczy każda uwaga.

Wdrażanie poprawek i retest

Ustal priorytety

Nie naprawiaj błędów w kolejności z raportu. Zacznij od tego, co blokuje najważniejsze zadania użytkowników, i dopiero potem idź szerzej:

  1. bariery w kluczowych ścieżkach – zakup, rejestracja, kontakt;
  2. komponenty wspólne – jedna poprawka w menu czy szablonie formularza usuwa problem z setek podstron;
  3. szybkie poprawki treści – teksty alternatywne, nagłówki, opisy linków;
  4. pozostałe problemy, rozplanowane na kolejne sprinty.

Zamień raport w zadania dla zespołu

Każdą pozycję z raportu zamień w zgłoszenie z kryterium, lokalizacją i warunkiem odbioru, np. „fokus widoczny na wszystkich przyciskach w nagłówku, sprawdzone klawiaturą”. Podziel pracę według ról: projektant poprawia kontrast i styl fokusu, programista semantykę, obsługę klawiatury i komunikaty, a redakcja teksty alternatywne i dokumenty. Przykłady typowych poprawek znajdziesz w zestawieniu najczęstszych błędów WCAG.

Poprawiaj u źródła: w motywie, bibliotece komponentów albo szablonie CMS, a nie na pojedynczych podstronach. Nakładki instalowane jednym skryptem nie naprawiają kodu strony i nie zastąpią tych zmian.

Zaplanuj retest

Po wdrożeniu poprawek audytor ponownie sprawdza zgłoszone problemy i nadaje im status: naprawiony, naprawiony częściowo albo otwarty. Warto przy tym zajrzeć do elementów, które poprawki mogły naruszyć – zmiana w jednym komponencie potrafi zepsuć inny. Liczbę rund retestu ustal przed startem prac, bo wpływa na koszt i harmonogram.

Gdzie pasuje raport automatyczny

Raport automatyczny nie jest audytem, ale dobrze go uzupełnia. Po pierwsze jako szybki pierwszy etap: jeśli przed audytem usuniesz oczywiste błędy, ekspert poświęci czas na to, czego automat nie oceni. Po drugie jako regularny monitoring między audytami, np. po każdym większym wdrożeniu lub zmianie motywu – żeby wyłapać regresje.

Na początek możesz uruchomić bezpłatny skan wstępny wybranej podstrony, a szerszy obraz da raport automatyczny obejmujący do 20 podstron. Pamiętaj tylko, że wynik automatu nie potwierdza zgodności z WCAG.

Najczęstsze pytania

Ile trwa audyt WCAG?

To zależy od zakresu: liczby szablonów, długości ścieżek, liczby formularzy oraz technologii asystujących, na których prowadzi się testy. Termin najlepiej ustalić z wykonawcą razem z próbką stron i liczbą rund retestu.

Jak często powtarzać audyt dostępności?

Pełny audyt warto powtórzyć po każdej dużej zmianie: redesignie, zmianie motywu albo wdrożeniu nowych procesów. Między audytami wystarczą regularne testy automatyczne i krótkie kontrole ręczne nowych funkcji.

Kto po stronie firmy powinien brać udział w audycie?

Osoba, która decyduje o zakresie i priorytetach, ktoś, kto zna serwis technicznie i przygotuje dostępy, oraz przedstawiciele zespołów wdrażających poprawki: projektant, programista i redakcja treści.

Czy audyt można przeprowadzić na wersji testowej strony?

Tak, to dobre rozwiązanie zwłaszcza przed premierą nowego serwisu. Wersja testowa powinna jednak odpowiadać produkcji – mieć te same szablony, treści i integracje – inaczej wyniki nie przełożą się na działającą stronę.