Audyt dostępności cyfrowej: zakres, testy WCAG i EAA

Ostatnio, pisząc artykuł o WCAG 2.1, przepuściłem 10 stron cometweb.io przez axe-core. Taki skan to pierwszy krok audytu dostępności cyfrowej i znalazł jedno naruszenie, akurat na mojej własnej stronie z cennikiem.

Sześć drobnych podpowiedzi 12 px miało kontrast 4,49:1 i 3,81:1 przy wymaganych 4,5:1, więc pierwszej zabrakło jednej setnej. Kontrast tekstu na jednolitym tle skaner policzy co do setnej. Ale czy klient dojdzie klawiaturą do płatności, na to pytanie wynik skanu milczy.

Resztę sprawdzasz sam, a poniżej masz checklistę i to, czego od sklepu wymaga polska wersja EAA.

Audyt dostępności cyfrowej: WCAG, EAA, PAD i EN 301 549

Audyt dostępności cyfrowej to sprawdzenie, czy użytkownik może odczytać treść i wykonać zadanie: znaleźć produkt, wypełnić formularz, zalogować się albo zapłacić. WCAG opisuje tylko wymagania techniczne, a obowiązki prawne określa Dyrektywa (UE) 2019/882 (European Accessibility Act, EAA) i wdrażająca ją polska ustawa.

Zgodność z WCAG 2.2 na poziomie AA wymaga spełnienia wszystkich kryteriów A i AA w ocenianym zakresie oraz warunków zgodności opisanych przez W3C.

Wydanie normy EN 301 549 a jej powołanie w Dzienniku Urzędowym UE

We wrześniu 2026 AccessibleEU ogłosiło publikację EN 301 549 V4.1.1, wydania z WCAG 2.2, ale powołanie normy w Dzienniku Urzędowym UE to osobny krok. Według przedmowy ETSI do V4.1.1 poprzednie wydanie, V3.2.1 z 2021 r. oparte na WCAG 2.1 AA, powołano tylko dla dyrektywy o stronach podmiotów publicznych. Dla EAA żadne wydanie nie daje więc dziś domniemania zgodności z art. 15 dyrektywy 2019/882, a V4.1.1 da je dopiero po powołaniu.

Jako cel techniczny nowego audytu polecam WCAG 2.2 AA, a wymagania prawne i umowne opisz w zamówieniu osobno, bo samo „audyt WCAG” albo „audyt EAA” zostawia zakres do zgadywania.

Kogo w Polsce obejmują obowiązki EAA?

Obowiązki EAA w Polsce wynikają z Polskiego Aktu o Dostępności (PAD), czyli ustawy z 26 kwietnia 2024 r., Dz.U. 2024 poz. 731, która zasadniczo obowiązuje od 28 czerwca 2025 r., więc termin już minął. Obejmuje wskazane produkty oraz usługi oferowane lub świadczone konsumentom (z wyjątkiem usług mikroprzedsiębiorców), między innymi handel elektroniczny, bankowość detaliczną, rozpowszechnianie e-booków i określone usługi związane z transportem.

Obowiązek wynika z usługi, a strona to tylko miejsce, w którym ją świadczysz. W sklepie liczy się więc cała droga do umowy z konsumentem, łącznie z kartą produktu, identyfikacją użytkownika, zabezpieczeniami i płatnością. Ministerstwo Cyfryzacji opisuje na stronie o e-handlu wymagania szczególne, które wskazuje art. 18 PAD.

Zanim ustalisz, czy obowiązek cię dotyczy, odpowiedz sobie na trzy pytania:

1. Jaką usługę świadczysz?
2. Komu ją oferujesz?
3. Czy zachodzi ustawowe wyłączenie?

Blog z formularzem kontaktowym nie staje się przez to usługą e-handlu, a etykieta „B2B” też nic nie rozstrzyga, jeśli z platformy korzystają również konsumenci. Jedno zastrzeżenie: ten materiał informacyjny i techniczny nie stanowi porady prawnej ani oceny zgodności konkretnej firmy, więc kwalifikację swojej działalności potwierdź z prawnikiem.

Mikroprzedsiębiorcy, starsze serwisy i zewnętrzne komponenty

Usługi oferowane lub świadczone przez mikroprzedsiębiorców wyłącza z obowiązków art. 4 pkt 1 PAD, ale obowiązki tej samej firmy związane z produktami zostają. Czy firma jest mikroprzedsiębiorcą, ustalasz według definicji z art. 7 Prawa przedsiębiorców (poradnik Ministerstwa Funduszy i Polityki Regionalnej): średniorocznie mniej niż 10 pracowników oraz obrót netto albo suma bilansowa do równowartości 2 mln euro w co najmniej jednym z dwóch ostatnich lat obrotowych.

Umowy o świadczenie usług zawarte przed startem obowiązków mogą według wąskich przepisów przejściowych PAD (art. 85, za EAA) trwać bez zmian do wygaśnięcia, najdłużej do 28 czerwca 2030 r. Do tej daty usługodawca może też używać produktów, których zgodnie z prawem używał wcześniej do podobnych usług.

Argument „to zewnętrzna wtyczka” też wymaga podstawy, bo wyłączenie obejmuje tylko treści stron trzecich, których dany podmiot nie finansuje, nie tworzy i nie kontroluje. Kupiony komponent koszyka czy płatności wymaga więc takiej samej oceny, a zakres napraw ustalasz z dostawcą.

Powołanie się na zasadniczą zmianę usługi lub nieproporcjonalne obciążenie wymaga oceny i dokumentacji, a w e-handlu także poinformowania właściwego organu (obowiązki informacyjne w PAD), a zwykłe „nie mamy teraz budżetu” tej procedury nie zastąpi.

Co sprawdzi automat, a co musi ocenić człowiek?

Automat dobrze łapie regresje, ale jego wynik zależy od reguł narzędzia i stanu strony. Skan bez logowania milczy o koncie klienta, a skan formularza przed wysłaniem pomija komunikaty błędów. W3C w przewodniku o wyborze narzędzi przyznaje, że narzędzia nie ocenią wszystkich aspektów dostępności, więc wiarygodnego „procentu dostępności” z liczby zaliczonych reguł nie wyliczysz.

Test przeglądarkowy otworzy modal, wyśle pusty formularz i sprawdzi focus, ale oceni tylko warunki, które ktoś wcześniej zapisał. Dlatego przy każdym wyniku pytam, co sprawdzono i jak. Skan dobrze zdejmuje z listy to, co da się policzyć, a mimo to części kontrastu w moim skanie cometweb.io axe nie rozstrzygnął.

Przykład: nazwany przycisk z pułapką klawiaturową

Przygotowałem dwa lokalne przykłady edukacyjne z przyciskiem „Zamów” i w obu Chromium udostępniało rolę button i nazwę Zamów. Pierwszy wariant miał celową blokadę klawisza Tab, więc po trzech naciśnięciach Tab, a osobno Shift+Tab, focus dalej stał na przycisku. W drugim, bez blokady, Tab przenosił focus do następnego linku, a Shift+Tab do poprzedniego pola.

Po ludzku: poprawna nazwa i rola stały obok pułapki, na której użytkownik klawiatury by utknął, a ujawnił ją dopiero osobny test interakcji. To sprawdzony przykład laboratoryjny w Playwright, bez axe-core i czytnika ekranu, więc to nie audyt CometWeb ani pomiar skanerów, a metodę i wyniki testu opisałem osobno.

Pułapki klawiaturowe opisuje kryterium 2.1.2 No Keyboard Trap, choć focus zatrzymany w otwartym modalu bywa poprawny, jeżeli komponent da się obsłużyć i opuścić klawiaturą.

Jak zaplanować audyt całej ścieżki użytkownika?

Plan audytu zaczyna się od zadań użytkownika, a adresy wybierasz potem. Jedna strona ma często kilka ważnych stanów, np. pusty formularz i walidację, ładowanie, timeout czy sukces. W aplikacji jednostronicowej adres potrafi zostać ten sam, choć ekran zmienia się całkowicie.

Dla sklepu przykładowy zakres obejmuje wyszukanie oferty i filtr, wybór wariantu i koszyk, dane klienta i dostawę, płatność, a na końcu potwierdzenie zamówienia. Do tego dochodzą ścieżki niepowodzenia (błędny kod pocztowy, odrzucona płatność, wygasła sesja i powrót bez utraty danych) oraz baner zgody, menu czy komunikaty, które pojawiają się ponad treścią. To moja propozycja, bo ustawa zostawia tę listę otwartą.

W dokumencie zakresu zapisz wersję aplikacji, konta testowe dla każdej roli, warianty językowe i objęte dokumenty. Dopisz użyte urządzenia, przeglądarki i technologie asystujące z wersjami, np. Windows z czytnikiem ekranu albo Safari z VoiceOver, a na końcu wyłączenia razem z powodem.

Checklista ręcznych testów po skanowaniu

Kontrole poniżej obejmują wybrane kryteria WCAG i większość z nich przejdziesz za darmo w zwykłej przeglądarce.

Klawiatura: całą ścieżkę przejdziesz bez myszy

Najważniejszą ścieżkę przejdź klawiszami Tab i Shift+Tab, bo każdy potrzebny element, np. przycisk, wybór opcji, menu czy modal, ma dać się osiągnąć i obsłużyć. Oceń kolejność focusu, jego powrót po zamknięciu warstwy i brak pułapek. Problem obsługi opisz w raporcie osobno od problemu widoczności focusu (warunki zgodności WCAG).

Według kryterium 2.4.11 AA element z focusem nie może być całkowicie zasłonięty przez treść utworzoną przez autora strony (Focus Not Obscured, Minimum).

Powiększenie i odstępy: tekst i układ wytrzymują ustawienia użytkownika

Powiększenie tekstu do 200% sprawdź z warunkami i wyjątkami kryterium 1.4.4 Resize Text. Osobno sprawdź układ przy szerokości odpowiadającej 320 pikselom CSS, czyli 1.4.10 Reflow.

Według W3C taką efektywną szerokość daje ekran 1280 pikseli CSS przy powiększeniu 400%, więc 400% na dowolnym ekranie to zły test. Wyjątki obejmują tylko treści wymagające układu dwuwymiarowego, a reszta strony nadal podlega testowi.

Dla kryterium 1.4.12 Text Spacing sprawdź, czy treść i funkcje zostają dostępne po ustawieniu interlinii 1,5 rozmiaru fontu, odstępu po akapicie 2 razy jego rozmiar, odstępu między literami 0,12 rozmiaru fontu i odstępu między słowami 0,16 rozmiaru fontu. To test odporności na ustawienia użytkownika, więc projekt może mieć własne wartości domyślne. W DevTools wystarczy dopisać te wartości w regule CSS dla wszystkich elementów.

Kontrast: tekst ma co najmniej 4,5:1 w rzeczywistym stanie komponentu

WCAG AA wymaga kontrastu co najmniej 4,5:1 dla zwykłego tekstu i 3:1 dla dużego, z określonymi wyjątkami (1.4.3 Contrast, Minimum). „Duży” ma w kryterium konkretną definicję, więc nagłówek nie jest duży z samej nazwy, a sprawdzać trzeba też komunikaty błędów i etykiety.

Kontrast elementów interfejsu i ich stanów to osobne kryterium, 1.4.11 Non-text Contrast, które nie wymaga obramowania każdego przycisku kontrastem 3:1.

Parę kolorów sprawdzisz za darmo w Contrast Checkerze, a całe strony skanuje moduł dostępności CometWeb Insight. Pokazuje bariery mierzalne automatycznie, w tym kontrast, a przy wyniku podaje kryterium WCAG i dowód na konkretnym elemencie.

Formularze i logowanie: błąd da się poprawić bez utraty danych

Wyślij formularz z pustymi i błędnymi danymi, a potem sprawdź opis błędu, jego powiązanie z polem i możliwość poprawy bez utraty wpisanych informacji (3.3.1 Error Identification). Etykieta ma zostać zrozumiała po wpisaniu tekstu, a placeholder przy pisaniu znika (3.3.2 Labels or Instructions).

Przy dynamicznych komunikatach sprawdź, czy technologia asystująca przekazuje informację bez zbędnego przenoszenia focusu. Kryterium 4.1.3 Status Messages nie wymaga aria-live="assertive" przy każdym powiadomieniu.

W logowaniu sprawdź współpracę z menedżerem haseł i wklejanie danych lub kodu. Kryterium 3.3.8 AA ogranicza wymaganie testu funkcji poznawczych bez dopuszczalnej alternatywy lub mechanizmu wsparcia i ma wyjątki, ale nie zakazuje wszystkich CAPTCHA ani nie wymaga usuwania zabezpieczeń.

WCAG 2.2: sześć dodatkowych kryteriów A i AA

Przy aktualizacji audytu z WCAG 2.1 dołóż do obowiązujących kryteriów poniższe dodatki. Komplet zmian i wyjątków zawiera tekst normatywny WCAG 2.2.

Reguła „każdy przycisk musi mieć 44 × 44” z 2.5.8 Target Size, Minimum nie wynika, bo kryterium ma wyjątki oceniane w kontekście elementu.

Jak powinien wyglądać raport z audytu dostępności?

Raport z audytu dostępności ma pozwolić odtworzyć problem i sprawdzić poprawkę. Dla każdego ustalenia zapisz więc ekran i stan, wersję aplikacji i środowisko oraz kroki odtworzenia. Obok daj wynik obserwowany i oczekiwany rezultat, powiązane kryterium i dowód oraz wpływ na użytkownika.

Do zadania dodaj właściciela i warunek ponownego testu, a materiały dowodowe anonimizuj. Poniżej szablon edukacyjny, bez usterki znalezionej w prawdziwym sklepie.

Tytuł: Focus pozostaje w zamkniętym panelu koszyka.
Zakres: widok produktu, panel otwarty z przycisku „Koszyk”.
Środowisko i wersja aplikacji: wpisać rzeczywiście użyte.
Kroki: otwórz panel klawiaturą, zamknij go, naciśnij Tab.
Obserwacja: zanotuj element, który faktycznie otrzymuje focus.
Oczekiwanie: focus trafia do logicznego elementu widocznej strony;
zwykle będzie to przycisk otwierający panel, chyba że proces się zmienił.
Mapowanie: oceń 2.4.3; nie dodawaj innych naruszeń bez ich potwierdzenia.
Retest: powtórz sekwencję oraz sprawdź następne Tab i Shift+Tab.
Status: NIE ZBADANO. Do wypełnienia po przeprowadzeniu testu.

Poziom A lub AA i priorytet zadania to dwie różne rzeczy. Priorytet ustal według wpływu na użytkownika:

• czy bariera blokuje płatność,
• ile ścieżek obejmuje,
• czy istnieje naprawdę dostępne obejście.

W wynikach rozróżniaj co najmniej pięć statusów: „spełnione w badanym zakresie”, „niespełnione”, „wymaga oceny”, „nie zbadano” oraz „nie dotyczy” z uzasadnieniem. Brak danych to brak danych, nigdy wynik pozytywny. Metodyka WCAG-EM 2.0, którą W3C opublikowało w lipcu 2026 jako Group Note, daje status „zgodne” tylko ekranom z próby. Tak samo działa mapa WCAG w module dostępności Insight, ze statusami „sprawdzone automatycznie”, „problem wykryty”, „wymaga ręcznej weryfikacji”, „nie dotyczy” i „brak danych”.

Retest i utrzymanie: kiedy problem jest naprawdę zamknięty?

Problem jest zamknięty, gdy użytkownik przechodzi scenariusz, który wcześniej go blokował. Po zmianie uruchom ponownie właściwy test automatyczny i powtórz ten scenariusz, a potem sprawdź też sąsiednie stany i ten sam komponent w innych miejscach, np. modal z koszyka w logowaniu.

W moim cenniku wystarczył ponowny skan axe obu wersji językowych, który pokazał zero naruszeń kontrastu. Pułapkę klawiaturową zamyka dopiero powtórzona ręcznie sekwencja Tab i Shift+Tab. Zapisz wersję poprawki, datę, osobę sprawdzającą i rezultat, a jeżeli potwierdzono tylko zmianę kodu, niewykonane testy zostaw osobno otwarte.

Usługa objęta PAD musi utrzymywać zgodność także po pierwszym raporcie, a ustawa przewiduje na to procedury i działania naprawcze. Ponowne sprawdzenia wiąż więc ze zmianami w kluczowych ścieżkach (logowanie, koszyk, płatność), treściach i komponentach, bo coroczna data w kalendarzu zostaje w tyle za wdrożeniami.

Jaką dokumentację przygotować dla usługi e-handlu?

Wzoru deklaracji dostępności z osobnej ustawy o dostępności cyfrowej z 2019 r. nie przenoś na prywatny sklep bez sprawdzenia i nie zakładaj, że EAA tę ustawę zastąpiło. Ocenę zgodności przeprowadza usługodawca, a PAD nie ustanawia uniwersalnego obowiązku zakupu zewnętrznego „certyfikatu WCAG”. Dokument od wykonawcy może potwierdzać przeprowadzoną ocenę, więc sprawdź jej zakres i podstawę oraz datę dowodów.

Raport z audytu pokazuje gotowość i dowody, a certyfikat zgodności to osobna sprawa. Informację o niespełnianiu wymagań i naprawach dostaje osobno organ, dla e-handlu minister właściwy do spraw informatyzacji.

Przy dokumentacji pomaga mapa wymaganie → element usługi → dowód → ograniczenie → działanie i retest. Publikuj tylko takie zapewnienie o zgodności, które potwierdzają twoje własne ustalenia.

Od czego zacząć audyt dostępności we własnym produkcie?

Łatwa część to skan, a trudna to przejście koszyka klawiaturą i uczciwe spisanie, czego jeszcze nie zbadałeś. Ja zacząłbym od tych czterech kroków, w tej kolejności:

1. Wyznacz odpowiedzialną osobę i spisz kluczowe zadania użytkownika.
2. Wybierz zakres pierwszego badania.
3. Uruchom skan i wykonaj testy interakcji.
4. Z potwierdzonych ustaleń ułóż kolejność napraw i plan retestu.

Zakres skanu sprawdź w metodologii CometWeb, a testy spoza niego zaplanuj osobno. Wybrane kontrole uporządkujesz w checkliście dostępności, a pracę udokumentujesz szablonami zakresu audytu, ustalenia i retestu, choć szablony obejmują tylko wybrane kryteria.

Jeśli wolisz zacząć od listy barier, załóż konto w Insight i uruchom pierwszy audyt, ale test klawiaturą i tak zrobisz sam. A jeśli planujesz audyt inaczej i u ciebie to działa, napisz do mnie: maciej@cometweb.io.

Najczęstsze pytania o audyt dostępności cyfrowej

Źródła i aktualność

Informacja o wydaniu EN 301 549 V4.1.1 pochodzi z komunikatu AccessibleEU z 7 września 2026 r. i potwierdza publikację normy. Aktualne powołanie normy w Dzienniku Urzędowym UE sprawdzaj osobno.

1. W3C WAI: Selecting Web Accessibility Evaluation Tools: możliwości i ograniczenia narzędzi.
2. Dyrektywa (UE) 2019/882, pełny tekst PL: zakres, domniemanie zgodności, wyłączenia i okresy przejściowe.
3. Polski Akt o Dostępności, ustawa z 26 kwietnia 2024 r., Dz.U. 2024 poz. 731: w szczególności art. 3–5, 18, 21, 32, 38 i 85.
4. W3C: Understanding Conformance: poziomy i warunki zgodności WCAG.
5. AccessibleEU: aktualizacja EN 301 549, 7 września 2026 r.: publikacja wydania a powołanie normy.
6. W3C: WCAG-EM 2.0, Group Note z 23 lipca 2026 r.: metodyka oceny i granice próbkowania.
7. W3C: Reflow, 1.4.10.
8. W3C: Text Spacing, 1.4.12.
9. W3C: Contrast (Minimum), 1.4.3.
10. W3C: WCAG 2.2, tekst normatywny: szczegółowe warunki i wyjątki kryteriów.
11. W3C: Target Size (Minimum), 2.5.8.
12. ETSI: EN 301 549 V4.1.1 (2026-09): przedmowa, dla których dyrektyw przygotowano wydania V3.2.1 i V4.1.1.