Mettre axe-core dans votre CI — détecter les régressions avant le merge

Corriger l'accessibilité une fois ne suffit pas : à la prochaine pull request, une régression peut tout casser sans que personne ne le voie. La parade est d'auditer automatiquement à chaque PR. axe-core tourne en CLI sur n'importe quel runner CI, l'intégration prend une quinzaine de minutes, et elle bloque le merge dès qu'une régression critique apparaît.

Snippet GitHub Actions

name: a11y
on: [pull_request]
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci && npm run build
      - run: npx @axe-core/cli http://localhost:3000 \
          --exit \
          --tags wcag2a,wcag2aa,wcag21aa

Ce que fait chaque étape

• →`on: [pull_request]` : l'audit se déclenche à chaque PR, avant le merge
• →`npm ci && npm run build` : on installe et on construit l'app, puis on la sert localement
• →`@axe-core/cli` : lance axe sur l'URL servie
• →`--exit` : renvoie un code d'erreur non nul si des violations sont trouvées — c'est ce qui fait échouer (et donc bloquer) la PR
• →`--tags` : limite l'analyse aux règles WCAG A et AA, le périmètre légalement pertinent

Le faire vraiment bloquer

Le `--exit` ne bloque que si la CI est configurée en check obligatoire. Dans les réglages de la branche protégée, marquez le job "a11y" comme requis pour le merge. Sans cela, le rouge s'affiche mais n'empêche personne de fusionner — la moitié du bénéfice est perdue.

Questions fréquentes

Sur combien d’URLs faire tourner axe ?

Au minimum vos gabarits clés : accueil, page catégorie, fiche produit, panier, checkout. Tester un exemplaire de chaque type de page attrape la majorité des régressions sans alourdir la CI.

axe va-t-il générer des faux positifs ?

axe-core est réputé pour son faible taux de faux positifs, mais aucun outil n'est parfait. Commencez en mode bloquant sur les violations "critical" et "serious", puis élargissez à mesure que vous nettoyez la base.

Cela remplace-t-il un audit RGAA ?

Non. Le CI empêche de régresser entre deux audits, mais il ne mesure pas la conformité RGAA complète ni les critères qui demandent un humain. Voyez-le comme un complément du suivi continu, pas comme un substitut.

Faut-il échouer la CI dès la première violation ?

Au démarrage, bloquez uniquement sur les violations "critical" et "serious", le temps de résorber la dette. Une fois la base nettoyée, vous pouvez resserrer pour tout bloquer. Bloquer sur tout d'emblée fige souvent la CI d'un site existant en rouge permanent.

Comment tester une page qui exige une connexion ?

Servez une session de test, ou injectez un cookie d'authentification dans le job avant de lancer axe sur les pages connectées (panier, checkout). C'est là que se cachent les pires non-conformités : l'effort en vaut la peine.

axe-core ralentit-il beaucoup le pipeline ?

Non : l'analyse d'une page prend quelques secondes. Le coût réel, c'est le `npm run build` et le démarrage du serveur, pas axe lui-même. Tester 5 gabarits clés ajoute typiquement moins d'une minute au job.

Peut-on l’utiliser hors GitHub Actions ?

Oui. `@axe-core/cli` tourne sur n'importe quel runner — GitLab CI, CircleCI, Jenkins, Bitbucket. Seule la syntaxe du fichier de pipeline change ; la commande axe reste identique.