Co zrobić po otrzymaniu raportu z audytu WCAG?

Raport z audytu dostępności to początek pracy nad poprawkami, a nie jej koniec. Po jego otrzymaniu ustal, które bariery najbardziej utrudniają użytkownikom korzystanie z serwisu, przypisz odpowiedzialność za ich usunięcie, zaplanuj wdrożenie i sprawdź, czy zmiany rzeczywiście działają.

Najkrótszy plan wygląda tak:

omów raport z osobami odpowiedzialnymi za serwis;
wyjaśnij niejasne wyniki i potwierdź zakres badania;
ustal priorytety według wpływu na użytkownika i ważności procesu;
przygotuj zadania z właścicielem, terminem i kryteriami odbioru;
wdrażaj poprawki i testuj je w rzeczywistych warunkach;
przeprowadź kontrolę po zmianach i zaktualizuj dokumentację.

1. Przeczytaj raport wspólnie z zespołem

Przekaż raport osobom, które mogą podjąć decyzje i wprowadzić zmiany: właścicielowi serwisu, redakcji, projektantom, programistom, osobie odpowiedzialnej za zamówienie lub dostawcę oraz koordynatorowi dostępności. Zorganizuj spotkanie, podczas którego zespół przejdzie przez wnioski, zakres badania i proponowane naprawy.

Raport powinien wskazywać, co i jak zbadano, gdzie występują problemy oraz jaki mają wpływ na użytkownika. Jeśli czegoś nie rozumiesz, poproś audytora o wyjaśnienie kryterium WCAG, scenariusza, zrzutu ekranu albo rekomendacji. Nie zamieniaj opisu błędu na zadanie programistyczne, zanim zespół nie rozumie, jaką barierę ma usunąć.

Ministerstwo Cyfryzacji zaleca, by po otrzymaniu wyników przekazać je zainteresowanym osobom i szybko rozpocząć pracę nad zaleceniami. Poradnik ministerstwa opisuje również, co zwykle zawiera raport z audytu eksperckiego.

2. Sprawdź zakres i ograniczenia badania

Raport opisuje stan serwisu w chwili badania i w zakresie, który objęto audytem. Sprawdź więc:

jakie podstrony i typy widoków przebadano;
czy audyt obejmował wersję mobilną, dokumenty i multimedia;
które procesy użytkownika przetestowano od początku do końca;
jakich przeglądarek, urządzeń i technologii asystujących użyto;
czy raport opisuje błędy wspólnych elementów, takich jak nagłówek, menu i stopka;
jakie elementy zostały wyłączone z badania i dlaczego.

Jeśli ważna część serwisu nie była objęta audytem, nie zakładaj, że jest wolna od barier. Ustal, czy potrzebne jest dodatkowe badanie, czy zespół potrafi samodzielnie sprawdzić ten zakres. Pamiętaj też, że poprawienie próby podstron nie zawsze naprawia wspólny komponent ani wszystkie miejsca użycia tego samego wzorca.

3. Ustal priorytety błędów

Nie każdy błąd ma taki sam wpływ. Uporządkuj wyniki według tego, komu i jak mocno utrudniają korzystanie z serwisu. Na początek wybierz problemy, które:

uniemożliwiają wykonanie ważnego zadania, na przykład wysłanie wniosku, zakup lub rejestrację;
blokują dostęp do kluczowej informacji;
powtarzają się na wielu podstronach, bo dotyczą wspólnego elementu;
szczególnie utrudniają obsługę klawiaturą lub czytnikiem ekranu;
mogą sprawić, że użytkownik straci wprowadzone dane albo nie dowie się, jak poprawić błąd;
mają prostą i dobrze rozpoznaną metodę naprawy.

Waga podana w raporcie jest ważną wskazówką, ale powinna iść w parze z kontekstem. Niski kontrast na przycisku kończącym płatność może być pilniejszy niż problem w rzadko odwiedzanej sekcji informacyjnej. Z kolei poprawienie błędu w szablonie strony może usunąć barierę w całym serwisie, więc warto potraktować je priorytetowo.

Nie sprowadzaj priorytetu do samego numeru kryterium WCAG. Kryterium mówi, jaki wymóg nie został spełniony; plan napraw powinien jeszcze uwzględnić realny skutek, zasięg i koszt zmiany.

4. Zamień raport na plan naprawczy

Każdy wykryty problem powinien trafić do narzędzia, w którym zespół prowadzi pracę: systemu zgłoszeń, arkusza lub planu projektu. Jedno zadanie może zawierać:

opis bariery i przykład miejsca, w którym występuje;
kryterium WCAG lub wymaganie wskazane w raporcie;
wpływ na użytkownika;
proponowane rozwiązanie albo link do uzgodnionej rekomendacji;
osobę odpowiedzialną i termin;
sposób sprawdzenia poprawki;
status: do wyjaśnienia, zaplanowane, w realizacji, do weryfikacji lub zamknięte.

Połącz błędy wynikające z tej samej przyczyny. Przykładowo, brak widocznego fokusu na wielu stronach może wynikać z jednego wspólnego stylu komponentów. Jedna dobrze zaplanowana zmiana może wtedy naprawić wiele wystąpień, a jej kryteria odbioru powinny obejmować wszystkie użycia tego komponentu.

Podziel plan na etapy, jeśli zespół nie może usunąć wszystkich barier od razu. Ustal kolejność z osobą decyzyjną, dostępny budżet i sposób informowania użytkowników o znanych problemach. Jeśli dotyczy Cię obowiązek publikowania deklaracji dostępności, opisuj stan zgodny z faktami i aktualizuj informacje, gdy zmiany wpływają na dostępność.

5. Wdrażaj poprawki i sprawdzaj je ręcznie

Po zmianie kodu lub treści sprawdź, czy usunięto przyczynę problemu, a nie tylko komunikat narzędzia. W zależności od błędu test może obejmować:

przejście całego procesu wyłącznie klawiaturą;
sprawdzenie kolejności i widoczności fokusu;
odczyt formularza i komunikatów błędów czytnikiem ekranu;
powiększenie treści i kontrolę układu na małym ekranie;
sprawdzenie nazw, etykiet, nagłówków i tekstów alternatywnych;
ponowne uruchomienie testu automatycznego jako dodatkowego sprawdzenia.

Po naprawie przetestuj również miejsca, które korzystają ze zmienionego elementu. Zmiana wspólnego komponentu może usunąć jeden problem, ale wywołać inny w nietypowym widoku. Automatyczny skan pomoże wykryć część regresji, ale sam nie potwierdzi, że proces jest zrozumiały i możliwy do ukończenia.

6. Zrób retest i udokumentuj wynik

Po wdrożeniu większej liczby poprawek zaplanuj ponowną weryfikację. Może ją wykonać zespół, który wdrażał zmiany, albo niezależny ekspert. Przy istotnych procesach, poważnych barierach lub niejasnych wynikach warto zlecić audyt weryfikujący.

Retest powinien sprawdzić, czy:

zgłoszony problem faktycznie zniknął;
poprawka działa w tych samych warunkach i technologiach asystujących;
nie powstały nowe błędy;
naprawiono wszystkie miejsca użycia wspólnego komponentu;
użytkownik może dokończyć zadanie, którego dotyczył problem.

Zapisuj datę weryfikacji, zakres, wynik, osobę sprawdzającą i ewentualne dalsze działania. Ministerstwo wskazuje, że raport z audytu weryfikującego może wymieniać błędy naprawione, nierozwiązane i nowe problemy wykryte po zmianach. Audyt weryfikujący zwykle uzupełnia raport podstawowy.

7. Zaktualizuj deklarację i zapobiegaj powrotowi błędów

Jeśli audyt wykrył bariery na stronie podmiotu publicznego, porównaj wyniki z jej deklaracją dostępności. Opis zgodności, niedostępnych treści, wyjątków i działań naprawczych powinien odpowiadać rzeczywistemu stanowi. Po wdrożeniu zmian sprawdź, czy deklaracja nadal jest aktualna; obowiązuje też coroczny przegląd deklaracji do 31 marca. Więcej wyjaśniamy w artykule Czy do przygotowania deklaracji dostępności potrzebny jest audyt?.

Żeby problemy nie wracały, dodaj dostępność do codziennego procesu publikowania i wytwarzania:

przygotuj redakcyjne wskazówki do tekstów, linków, nagłówków i obrazów;
używaj sprawdzonych komponentów interfejsu;
uwzględnij testy klawiaturą i czytnikiem ekranu w odbiorze zmian;
przeszkol osoby, które tworzą treści i rozwijają serwis;
ustal, kto monitoruje zgłoszenia użytkowników i nowe bariery.

Raport jest zdjęciem stanu w konkretnym momencie. Nowa funkcja, aktualizacja systemu lub świeżo opublikowany dokument mogą wprowadzić kolejne problemy, dlatego dostępność trzeba sprawdzać również po zakończeniu audytu.

Najczęstsze błędy po otrzymaniu raportu

Odkładanie raportu do szuflady. Wtedy problemy pozostają, a wyniki szybko tracą aktualność. Ustal pierwsze zadania i terminy bezpośrednio po omówieniu raportu.

Naprawianie wyłącznie błędów z automatycznego skanera. Część istotnych barier wymaga ręcznej oceny, pracy z technologią asystującą lub przejścia pełnego procesu.

Przepisanie rekomendacji bez testu. Zmiana może wyglądać poprawnie w kodzie, a nadal nie działać dla użytkownika. Każde zadanie musi mieć kryterium weryfikacji.

Traktowanie deklaracji jak potwierdzenia pełnej zgodności. Deklaracja informuje o stanie dostępności; nie zastępuje badania ani nie naprawia serwisu.

Brak osoby odpowiedzialnej. Jeśli zadanie nie ma właściciela, terminu i sposobu odbioru, łatwo utknie między redakcją, projektantem i programistą.

Co zrobić po raporcie z audytu WCAG? Podsumowanie

Najpierw omów zakres i wyniki raportu, potem ustal kolejność napraw według wpływu barier na użytkowników. Każdy problem zamień na konkretne zadanie z odpowiedzialną osobą i kryterium odbioru. Po wdrożeniu sprawdź rozwiązanie ręcznie, wykonaj retest, zapisz wynik i zaktualizuj deklarację, jeśli opis nie odpowiada już stanowi strony.

Jeśli dopiero przygotowujesz się do audytu, przeczytaj także artykuł Na czym polega audyt WCAG i co powinien zawierać raport?. Podstawowe problemy możesz wstępnie sprawdzić również przez darmowy test dostępności strony, pamiętając, że skan automatyczny nie zastępuje ręcznej oceny.

Stan informacji: 1 października 2026 r.

Powiązane poradniki

Przykład: zamiana wyniku audytu na zadanie

Wpis w raporcie „brak etykiety pola” warto rozbić na konkretne działanie i sprawdzalny warunek ukończenia:

Pole zadania	Przykład
Miejsce	Formularz zapisu do newslettera, pole adresu e-mail
Problem	Czytnik ekranu nie rozpoznaje celu pola
Działanie	Dodać widoczną etykietę powiązaną z polem przez `for` i `id`
Odbiór	Sprawdzić odczyt etykiety i przejście klawiaturą w przeglądarce

<label for="newsletter-email">Adres e-mail</label>
<input id="newsletter-email" name="email" type="email" required>

Po wdrożeniu sprawdź zarówno sam komponent, jak i cały proces: komunikat błędu, poprawienie wartości oraz potwierdzenie wysłania formularza.