pa11y i axe do testowania dostępności

Pa11y i axe-core to narzędzia open source automatyzujące testowanie dostępności zgodne z WCAG. Oba analizują stronę, uruchamiają reguły względem DOM i zgłaszają naruszenia. Automatycznie można wykryć większość problemów z dostępnością, a testy ręczne należy pozostawić dla pozostałych.

axe-core to biblioteka JavaScript zasilająca audyty dostępności w Chrome DevTools, Lighthouse, Jest, Cypress, Playwright i wielu innych narzędziach. Jest faktycznym standardem automatycznego testowania dostępności — oferuje szerokie pokrycie reguł i niewiele wyników fałszywie dodatnich.

Rozszerzenie przeglądarkowe axe DevTools (Chrome, Firefox, Edge) dodaje do DevTools kartę „Accessibility”. Po kliknięciu „Scan all pages” wyświetla ono każde naruszenie wraz z elementami, których dotyczy, poziomem ważności i wskazówkami dotyczącymi naprawy. Najlepiej nadaje się do jednorazowych audytów podczas programowania.

Pa11y to narzędzie CLI dla Node.js: npx pa11y https://example.com audytuje wskazany adres URL. Wyświetla listę problemów w terminalu. Można go używać do szybkich audytów, w skryptach powłoki lub do integracji z CI o niewielkim narzucie.

Połączenie axe-core z Playwright umożliwia testowanie dostępności end-to-end: const results = await new AxeBuilder({ page }).analyze(). Należy sprawdzić, czy results.violations.length === 0. Pozwala to wykrywać regresje, zanim trafią do środowiska produkcyjnego.

jest-axe uruchamia axe dla wyrenderowanych komponentów w testach Jest. Komponent należy wyrenderować za pomocą React Testing Library, a następnie przekazać kontener do axe: expect(await axe(container)).toHaveNoViolations(). Każdy test komponentu obejmuje teraz również sprawdzenie dostępności.

Oba narzędzia pozwalają wyłączać lub modyfikować reguły dla poszczególnych projektów: wyłączać reguły sprzeczne z celowymi decyzjami projektowymi i zwiększać rygor dla znanych reguł o krytycznym znaczeniu. Każdą wyłączoną regułę należy udokumentować komentarzem wyjaśniającym powód — to kontekst potrzebny przyszłym programistom.

Narzędzia automatyczne wykrywają około 30–40% problemów WCAG. Pozostałe (sensowna kolejność fokusu, czytelny tekst alternatywny, semantyczna hierarchia nagłówków, użycie ARIA odzwierciedlające rzeczywiste zachowanie interfejsu) wymagają przeglądu dokonanego przez człowieka. Automatyzacja jest konieczna, ale niewystarczająca do zapewnienia dostępności.

Należy testować z użyciem NVDA w systemie Windows, VoiceOver na komputerach Mac oraz JAWS w przypadku odbiorców korporacyjnych. Testowanie z rzeczywistym czytnikiem ekranu ujawnia problemy, których automatyzacja nie wykrywa — niezrozumiałe komunikaty, niedziałające punkty orientacyjne i nielogiczną kolejność fokusu. Test raz na wydanie dla każdego głównego czytnika ekranu to rozsądny punkt wyjścia.

Najcenniejsza walidacja dostępności pochodzi od osób z niepełnosprawnościami korzystających z rzeczywistego produktu. Uczestników można rekrutować za pośrednictwem firm doradczych ds. dostępności, akademickich biur ds. niepełnosprawności lub platform testowych takich jak UserTesting.com. Ich opinie oparte na rzeczywistym użytkowaniu ujawniają problemy, których nie wykrywa żadne narzędzie automatyczne.

Należy blokować PR-y w przypadku regresji dostępności (nowych naruszeń), ale nie w przypadku naruszeń zastanych (istniejącego punktu odniesienia). Pozwala to podnosić wymagania bez blokowania wdrożeń. Z czasem warto śledzić całkowitą liczbę naruszeń jako wczesny wskaźnik ogólnego stanu dostępności.

Należy używać wielu narzędzi: axe do kompleksowego sprawdzenia automatycznego, Pa11y jako drugiej opinii oraz ręcznego testowania z czytnikiem ekranu w celu uzupełnienia luki jakościowej. Zakresy ich działania pokrywają się w niewielkim stopniu; razem wykrywają więcej problemów niż którekolwiek pojedyncze narzędzie.

Jaki odsetek problemów z dostępnością zgodnych z WCAG można wiarygodnie wykryć za pomocą narzędzi automatycznych, takich jak axe i Pa11y?

axe-core zasila większość audytów dostępności; rozszerzenie przeglądarkowe świetnie nadaje się do jednorazowych kontroli, a integracje jest-axe i Playwright — do ciągłego testowania. Pa11y to uzupełniające narzędzie CLI. Automatyzacja wykrywa około 30–40% problemów; w celu pełnego pokrycia należy połączyć ją z ręcznym testowaniem przy użyciu czytników ekranu (NVDA, VoiceOver) oraz testami z udziałem osób z niepełnosprawnościami. W CI należy blokować nowe regresje, ale nie blokować procesu z powodu naruszeń zastanych w punkcie odniesienia.