axe-core
Zob. też: axe
Otwartoźródłowy silnik automatycznego testowania dostępności firmy Deque, używany przez rozszerzenia przeglądarek (axe DevTools, Accessibility Insights), skrypty CI i Lighthouse. Wykrywa szacunkowo 30–40% problemów z WCAG.
axe-core to otwartoźródłowy silnik automatycznego testowania dostępności opracowany przez Deque Systems. Napędza szeroki ekosystem narzędzi testowych — rozszerzenia przeglądarek (axe DevTools, Accessibility Insights), skrypty CI (axe-cli, jest-axe, cypress-axe, playwright-axe) i, co najważniejsze, audyt dostępności w Lighthouse.
Przez ostatnią dekadę axe-core był najszerzej wdrożonym automatycznym sprawdzaniem dostępności na świecie. Większość potoków CI związanych z dostępnością w produkcji dziś korzysta z axe-core pod spodem, często bez wiedzy zespołu.
Co axe-core robi dobrze
Zestaw reguł axe-core jest z założenia konserwatywny: reguła jest włączana tylko wtedy, gdy jej wskaźnik fałszywych trafień jest zasadniczo zerowy. Dzięki temu axe-core jest wiarygodną bramką CI — gdy oznaczy naruszenie, naruszenie jest prawdziwe i zespół może działać bez obaw o goniotwórstwo za niestabilnymi sprawdzeniami.
Reguły niezawodnie wykrywane przez axe-core:
- Brakujące lub puste etykiety na elementach sterujących formularzy.
- Brakujące atrybuty alt (i oczywiście bezużyteczne alt, jak nazwy plików).
- Niewystarczający kontrast kolorów (tekstu i komponentów interfejsu).
- Nieprawidłowe użycie ARIA — nieistniejące role, brakujące wymagane właściwości, niedozwolone struktury elementów potomnych.
- Zduplikowane identyfikatory psujące odwołania ARIA.
- Brakujący atrybut języka w elemencie
<html>. - Przyciski bez dostępnej nazwy.
- Pola formularzy bez programowej etykiety.
- Puste łącza (
<a href>...</a>bez tekstu lub alt). - Pomijanie poziomów nagłówków i brak
<h1>w niektórych konfiguracjach.
Ta lista obejmuje znaczący odsetek nisko wiszących owoców błędów dostępności. Uruchomienie axe-core w CI wyłapuje je na etapie przeglądu kodu, a nie dopiero podczas audytu.
Sufit możliwości
Autorzy axe-core są otwarci co do ograniczeń: automatyczne narzędzia mogą wykryć co najwyżej 30–40% problemów z WCAG. Reszta wymaga ludzkiego osądu i testowania za pomocą technologii asystujących.
Czego axe-core nie może wykryć:
- Błędnego tekstu alternatywnego — może powiedzieć, że alt brakuje, ale nie że
alt="ikona hamburgera"jest błędny dla przycisku otwierającego menu. - Mylącego tekstu łącza — łącza „Kliknij tutaj” są zgodne ze specyfikacją, ale bezużyteczne dla użytkowników czytników ekranu.
- Nieprawidłowej kolejności fokusa — kolejność tabulatora niezgodna z kolejnością wizualną to naruszenie 2.4.3, którego żaden statyczny sprawdzacz nie wykryje.
- Nieprawidłowej struktury nagłówków — axe-core wykrywa brak h1 i pomijanie poziomów, ale nie może stwierdzić, że strona użyła h2 tam, gdzie powinno być h1.
- Treści działających tylko dla niektórych grup użytkowników — zgodnej z WCAG, ale nieużywalnej dla osób niedowidzących, z niepełnosprawnościami poznawczymi itp.
Witryna z zerową liczbą naruszeń w axe-core jest konieczna dla dostępności, ale nie wystarczająca. Pozostała praca — kolejność fokusa, jakość treści, zachowanie czytnika ekranu, testy z prawdziwymi użytkownikami — zajmuje większość czasu.
Jak operacyjnie korzystać z axe-core
Trzy wzorce wdrożenia dobrze się uzupełniają:
- W edytorze. axe DevTools i Accessibility Insights uruchamiane na żądanie względem renderowanego DOM w karcie przeglądarki. Używaj podczas rozwoju.
- W CI. axe-cli, jest-axe, cypress-axe lub playwright-axe powodują nieudane buildy przy nowych naruszeniach. Używaj, by zapobiegać regresjom.
- Podczas audytu. Zewnętrzni audytorzy uruchamiają axe-core jako punkt wyjścia, a następnie nakładają ręczne testowanie. Używaj do walidacji automatycznej linii bazowej.
Kombinacja ta utrzymuje automatycznie wykrywalne problemy na poziomie zera, podczas gdy prawdziwy program dostępności zajmuje się resztą.