Trois engines open-source reviennent dans toutes les stacks d'accessibilité : axe-core, Lighthouse et Pa11y. On les oppose souvent, à tort : ils ne servent pas la même chose. Voici quand utiliser chacun, et comment ils se complètent.

axe-core — la précision maximale

Maintenu par Deque. Le catalogue de règles le plus large et le plus à jour, le moins de faux positifs. C'est l'engine de référence pour un audit sérieux et pour le blocage en CI. Quand vous voulez un verdict fiable, issue par issue, c'est lui.

Lighthouse — le score rapide

Inclus dans Chrome DevTools. Il utilise axe-core en moteur, mais sur un sous-ensemble de règles, et restitue un score 0-100. Parfait pour suivre une tendance ou montrer un chiffre à un dirigeant, insuffisant pour décider d'un correctif : les détails manquent.

Pa11y — le crawl scriptable

Outil en ligne de commande plus ancien, taillé pour passer des sites entiers en revue en batch. Moins à jour qu'axe sur les règles, mais commode en cron sur des milliers de pages. On l'utilise pour la couverture, pas pour la finesse.

Le verdict pratique

  • →Audit ponctuel sérieux : axe-core (via un outil dédié ou seul)
  • →Tableau de bord à montrer à un dirigeant : Lighthouse
  • →Crawl complet d'un site de 10 000 pages en interne : Pa11y
  • →Pipeline CI/CD bloquant à la PR : axe-core CLI

// Le point commun, et la limite commune

Les trois reposent, directement ou indirectement, sur des règles automatisables — soit 30 à 40 % des critères. Aucun ne juge la pertinence d'un alt ni le comportement réel sous lecteur d'écran. Empiler les trois ne couvre pas plus de critères : cela couvre plus de pages, plus vite, pour le même périmètre de règles.

Questions fréquentes

Faut-il utiliser les trois ?

Rarement. axe-core couvre l'essentiel pour l'audit et le CI ; Lighthouse ajoute le score de pilotage ; Pa11y n'a de sens que pour des crawls massifs. Pour la plupart des sites, axe-core seul, bien utilisé, suffit côté automatisé.

Lequel pour bloquer une CI ?

axe-core CLI, avec son option de sortie en erreur sur violation. C'est le plus fiable et le plus précis pour empêcher une régression de passer en production.

Ces outils mesurent-ils le RGAA ?

Non, ils mesurent la WCAG. Pour un verdict RGAA, il faut une couche qui mappe et complète vers les critères français — ce qu'un audit dédié ajoute par-dessus le moteur.

Lighthouse et axe donnent-ils le même score ?

Pas exactement. Lighthouse n'exécute qu'un sous-ensemble des règles d'axe-core et pondère son score à sa façon. Un "100" en accessibilité Lighthouse ne signifie donc pas "zéro violation axe" : c'est un indicateur de tendance, pas un verdict d'audit.

Peut-on faire tourner Pa11y et axe ensemble ?

Oui, et c'est une combinaison courante : Pa11y pour balayer des milliers d'URLs en batch, axe-core pour un verdict précis sur les pages clés. Ils ne se concurrencent pas, ils couvrent deux besoins différents — la largeur et la profondeur.

Ces outils détectent-ils les problèmes au clavier ?

Très partiellement. Ils repèrent l'absence de nom accessible ou un `tabindex` aberrant, mais pas si la navigation au clavier fonctionne réellement de bout en bout. Ce test-là reste manuel, quel que soit l'engine.

Lequel choisir si je ne dois en garder qu’un ?

axe-core. C'est le plus précis, le plus à jour, et il sert aussi bien l'audit ponctuel que le blocage en CI. Lighthouse et Pa11y sont des compléments selon le besoin : score de pilotage, ou crawl massif.

Un audit RGAA qui s'appuie sur axe-core et va plus loin :

→ Lancer un audit