axe-core — glossaire de l’accessibilité

axe-core est le moteur de test d’accessibilité automatisé open source développé par Deque Systems. Il alimente un large écosystème d’outils de test — extensions de navigateur (axe DevTools, Accessibility Insights), scripts CI (axe-cli, jest-axe, cypress-axe, playwright-axe), et notamment l’audit d’accessibilité de Lighthouse.

Depuis une décennie, axe-core est le vérificateur d’accessibilité automatisé le plus déployé au monde. La plupart des pipelines CI liés à l’accessibilité actuellement en production font tourner axe-core sous le capot, souvent sans que les équipes le réalisent.

Ce qu’axe-core fait bien

L’ensemble de règles d’axe-core est conservateur par conception : une règle n’est incluse que lorsque son taux de faux positifs est essentiellement nul. Cela rend axe-core fiable comme porte CI — lorsqu’il signale une violation, la violation est réelle et l’équipe peut agir sans se soucier d’une chasse aux vérifications instables.

Les règles qu’axe-core détecte de façon fiable incluent :

Labels manquants ou vides sur les contrôles de formulaire.
Attributs alt manquants (et alt manifestement inutile comme des noms de fichiers).
Contraste des couleurs insuffisant (texte et composants d’interface).
ARIA invalide — rôles inexistants, propriétés requises manquantes, structures d’enfants interdites.
IDs en double qui brisent les références ARIA.
Attribut de langue manquant sur <html>.
Boutons sans nom accessible.
Champs de formulaire sans étiquette programmatique.
Liens vides (<a href>...</a> sans texte ni alt).
Sauts de niveaux de titre et absence de <h1> dans certaines configurations.

Cette liste couvre un pourcentage significatif des erreurs d’accessibilité les plus faciles à corriger. Exécuter axe-core en CI les détecte au moment de la revue de code plutôt qu’au moment de l’audit.

Le plafond

Les auteurs d’axe-core sont explicites sur le plafond : les outils automatisés peuvent détecter au maximum 30 à 40 % des problèmes WCAG. Le reste requiert un jugement humain et des tests avec des technologies d’assistance.

Plus précisément, axe-core ne peut pas détecter :

Un texte alternatif incorrect — il peut signaler qu’un alt est absent, mais pas que alt="icône hamburger" est erroné pour un bouton qui ouvre un menu.
Un texte de lien trompeur — les liens « Cliquez ici » sont conformes à la spécification, mais inutiles pour les utilisateurs de lecteurs d’écran.
Un ordre de focus brisé — un ordre de tabulation qui ne correspond pas à l’ordre visuel constitue un échec au critère 2.4.3 qu’aucun vérificateur statique ne peut détecter.
Une structure de titres incorrecte — axe-core détecte l’absence de h1 et les sauts de niveaux, mais ne peut pas déterminer qu’une page a utilisé h2 là où h1 aurait été approprié.
Du contenu qui ne fonctionne que pour certains groupes d’utilisateurs — conforme à WCAG mais inutilisable pour les personnes malvoyantes, les personnes ayant des déficiences cognitives, etc.

Un site qui obtient zéro violation dans axe-core est une condition nécessaire pour l’accessibilité, mais non suffisante. Le travail restant — ordre de focus, qualité du contenu, comportement avec les lecteurs d’écran, tests avec de vrais utilisateurs — représente la majeure partie du temps réel.

Comment utiliser axe-core en pratique

Trois modes de déploiement fonctionnent bien ensemble :

Dans l’éditeur. axe DevTools et Accessibility Insights s’exécutent à la demande sur le DOM rendu dans un onglet de navigateur. À utiliser pendant le développement.
En CI. axe-cli, jest-axe, cypress-axe ou playwright-axe font échouer le build en cas de nouvelles violations. À utiliser pour prévenir les régressions.
Au moment de l’audit. Les auditeurs externes utilisent axe-core comme point de départ, puis superposent des tests manuels. À utiliser pour valider la base de référence automatisée.

Cette combinaison maintient les problèmes détectables automatiquement à zéro tandis qu’un véritable programme d’accessibilité traite le reste.