Pa11y

Pa11y est un outil d’audit d’accessibilité automatisé et open-source. Développé à l’origine au sein du Nature Publishing Group, il est aujourd’hui maintenu par une communauté indépendante. Pa11y s’est imposé depuis une décennie comme la référence pour les « tests d’accessibilité en intégration continue ».

Ce que fait Pa11y

En ligne de commande, Pa11y prend une URL et effectue des vérifications d’accessibilité sur la page rendue, puis génère une liste de violations :

$ pa11y https://example.com
Welcome to Pa11y

> Running Pa11y on 1 URLs:
...

Error: This element does not have an attribute "alt".
   • Element: <img src="..." />
   • Code: HTML_CS.Principle1.Guideline1_1.1_1_1.H37
   • Selector: body > section:nth-child(2) > img

Pa11y s’exécute dans un navigateur sans interface graphique (Puppeteer ou Playwright sous le capot), si bien qu’il analyse le DOM rendu — et non simplement le HTML source — et peut auditer les contenus produits par JavaScript exactement comme un utilisateur les rencontrerait.

Les moteurs de règles supportés

Pa11y a historiquement pris en charge deux moteurs de règles :

• HTML_CodeSniffer (celui par défaut ; le moteur d’origine de Pa11y).
• axe-core (via pa11y --runner axe).

Il est possible d’utiliser les deux simultanément et de fusionner les résultats — un mode « tout ce que je peux détecter automatiquement ». La plupart des déploiements Pa11y modernes utilisent exclusivement le moteur axe-core, dont le développement des règles est le plus actif.

pa11y-ci — le workflow multi-URL

Le cas d’usage principal est pa11y-ci, un wrapper qui exécute Pa11y sur de nombreuses URLs en une seule fois et retourne un code de sortie adapté à l’intégration continue :

$ pa11y-ci --sitemap https://example.com/sitemap.xml

C’est précisément le workflow que la plupart des programmes d’accessibilité adoptent pour les régressions nocturnes : on alimente pa11y-ci avec le sitemap du site via une tâche cron, on fait échouer le build dès qu’une nouvelle violation apparaît, et on alerte lorsque le nombre de violations augmente.

La configuration se définit dans .pa11yci (ou un fichier JSON), permettant des exclusions par URL, des seuils de gravité, des tailles de viewport, des actions personnalisées (connexion, navigation par clics) et d’autres automatisations.

Pa11y vs axe-core vs Lighthouse

Un modèle mental raisonnable :

• axe-core est le moteur de règles — la bibliothèque de détection sous-jacente. On y accède via un wrapper.
• Lighthouse est un wrapper, optimisé pour les audits qualité complets d’un site (Performance + Accessibilité + Bonnes pratiques + SEO).
• Pa11y est un autre wrapper, optimisé pour le blocage CI axé sur l’accessibilité seule, sur de nombreuses URLs à grande échelle.
• axe-core CLI est le troisième — axe nu, sans wrapper Pa11y, également compatible avec l’intégration continue.

Pour les analyses approfondies page par page, Lighthouse est préférable. Pour les tests de régression à l’échelle du site avec de nombreuses URLs, Pa11y est la valeur par défaut pratique. Pour les vérifications bloquant les pull requests sur une URL unique, axe-core CLI et Lighthouse-CI fonctionnent tous deux très bien.

Limites

Pa11y hérite de toutes les limites des outils automatisés :

• 30 à 40 % des problèmes WCAG sont détectables automatiquement ; le reste nécessite un jugement humain.
• Il ne peut pas tester la navigation au clavier, l’ordre de focus ni le comportement des lecteurs d’écran.
• Il s’exécute dans un navigateur sans interface graphique et ne peut donc pas détecter les problèmes qui n’apparaissent que lors d’une interaction utilisateur réelle (clics répétés, abandon de formulaire, empilement inattendu de modales).

Mais dans les limites de la détection automatisée, Pa11y est l’outil le plus flexible sur le plan opérationnel parmi les principales options — en particulier lorsque le périmètre de l’audit est « l’ensemble du site, chaque nuit » plutôt que « cette pull request spécifique ».