Pa11y et axe pour les tests d’accessibilité

Pa11y et axe-core sont des outils open source qui automatisent les tests d’accessibilité conformes à WCAG. Tous deux analysent une page, appliquent des règles au DOM et signalent les violations. Détectez automatiquement la majorité des problèmes d’accessibilité et réservez les tests manuels aux autres.

axe-core est une bibliothèque JavaScript qui alimente les audits d’accessibilité de Chrome DevTools, Lighthouse, Jest, Cypress, Playwright et de nombreux autres outils. C’est le standard de fait des tests d’accessibilité automatisés : large couverture de règles et faible taux de faux positifs.

L’extension de navigateur axe DevTools (Chrome, Firefox, Edge) ajoute un onglet "Accessibilité" à DevTools. Cliquez sur "Analyser toutes les pages" ; elle répertorie chaque violation avec les éléments concernés, la gravité et des conseils de correction. Elle convient particulièrement aux audits ponctuels pendant le développement.

Pa11y est une interface CLI Node.js : npx pa11y https://example.com audite une URL. Elle affiche une liste de problèmes dans le terminal. Utilisez-la pour des audits rapides, dans des scripts shell ou pour une intégration légère au pipeline d’intégration continue.

Combinez axe-core à Playwright pour effectuer des tests d’accessibilité de bout en bout : const results = await new AxeBuilder({ page }).analyze(). Vérifiez que results.violations.length === 0. Cela détecte les régressions avant leur mise en production.

jest-axe exécute axe sur des composants rendus dans les tests Jest. Rendez le composant avec React Testing Library, transmettez le conteneur à axe : expect(await axe(container)).toHaveNoViolations(). Chaque test de composant inclut désormais une vérification d’accessibilité.

Les deux outils vous permettent de désactiver ou de modifier les règles pour chaque projet : désactivez les règles qui entrent en conflit avec des choix de conception délibérés et renforcez les règles connues comme critiques. Documentez chaque règle désactivée à l’aide d’un commentaire expliquant pourquoi, afin de fournir le contexte dont les futurs développeurs auront besoin.

Les outils automatisés détectent environ 30 à 40 % des problèmes WCAG. Le reste (ordre de navigation par le focus, texte alternatif pertinent, hiérarchie sémantique des titres, utilisation d’ARIA reflétant le comportement réel de l’interface) nécessite une vérification humaine. L’automatisation est nécessaire, mais elle ne suffit pas pour garantir l’accessibilité.

Testez avec NVDA sous Windows, VoiceOver sur Mac et JAWS pour les publics professionnels. Les tests avec de vrais lecteurs d’écran révèlent des problèmes que l’automatisation ne peut pas détecter : annonces déroutantes, repères défaillants et ordre de navigation par le focus illogique. Une fois par version pour chaque lecteur d’écran majeur constitue une référence raisonnable.

La validation d’accessibilité la plus utile vient de personnes handicapées qui utilisent le produit réel. Recrutez-les par l’intermédiaire de cabinets spécialisés en accessibilité, de services universitaires dédiés au handicap ou de plateformes de test comme UserTesting.com. Leurs retours en situation réelle révèlent des problèmes qu’aucun outil automatisé ne fait apparaître.

Bloquez les PR en cas de régressions d’accessibilité (nouvelles violations), mais pas en cas de violations héritées (référence existante). Le niveau d’exigence progresse ainsi sans bloquer les mises en production. Suivez au fil du temps le nombre total de violations comme indicateur précoce de l’état général de l’accessibilité.

Utilisez plusieurs outils : axe pour la vérification automatisée complète, Pa11y comme second avis et les tests manuels avec un lecteur d’écran pour combler l’écart qualitatif. Leur recouvrement est limité ; ensemble, ils couvrent davantage de problèmes qu’un seul outil ne peut en détecter.

Quel pourcentage des problèmes d’accessibilité WCAG les outils automatisés comme axe et Pa11y peuvent-ils détecter de manière fiable ?

axe-core alimente la plupart des audits d’accessibilité ; l’extension de navigateur convient parfaitement aux vérifications ponctuelles, tandis que les intégrations jest-axe et Playwright permettent des tests continus. Pa11y est une interface CLI complémentaire. L’automatisation détecte environ 30 à 40 % des problèmes ; associez-la à des tests manuels avec un lecteur d’écran (NVDA, VoiceOver) et à des tests menés auprès de personnes handicapées pour une couverture complète. Bloquez les nouvelles régressions dans le pipeline d’intégration continue sans bloquer sur la référence héritée.