Vérifier l'accessibilité à chaque mise à jour (intégration continue)

La ligne de commande d'Accessia audite vos pages à chaque mise à jour du site, dans GitHub Actions ou une autre CI, et fait échouer la vérification quand une non-conformité apparaît : une régression d'accessibilité est arrêtée avant d'atteindre vos visiteurs.

Mis à jour le 27 octobre 2026

Relier votre compte

Il faut Node.js 18 ou plus récent et un compte Accessia (gratuit). Rien à installer : npx télécharge l'outil.

1. Dans un terminal, créez une clé pour la CI : npx accessia connexion --ci
2. Votre navigateur ouvre Accessia. Vérifiez que la page affiche le même code que le terminal, puis cliquez sur « Autoriser ».
3. Le terminal affiche la clé, une seule fois. Dans votre dépôt GitHub : « Settings » → « Secrets and variables » → « Actions » → « New repository secret », nom ACCESSIA_API_KEY, valeur : la clé.

Pour lancer des audits depuis votre propre poste, npx accessia connexion (sans --ci) enregistre la clé sur le poste.

Premier audit

npx accessia audit https://www.exemple.fr https://www.exemple.fr/contact

Pour chaque page : le taux provisoire de l'analyse automatique, les critères non conformes avec leur gravité et le lien du rapport dans votre compte. Le code de sortie vaut 0 si la barrière est franchie, 1 s'il reste trop de non-conformités, 2 en cas d'erreur (clé, crédits, page injoignable).

GitHub Actions : vérifier le site en ligne

Créez le fichier .github/workflows/accessibilite.yml dans votre dépôt, en remplaçant les adresses par les vôtres :

name: Accessibilité
on:
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  accessia:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - name: Audit Accessia
        run: npx -y accessia audit https://www.exemple.fr https://www.exemple.fr/contact
        env:
          ACCESSIA_API_KEY: ${{ secrets.ACCESSIA_API_KEY }}

À chaque mise à jour de la branche main, la page du lancement affiche un résumé (taux, non-conformités, liens des rapports) et chaque nouvelle non-conformité apparaît en annotation.

GitHub Actions : vérifier une modification avant de la publier

Le site est construit et lancé dans la CI, puis audité sur localhost : son code est lu sur la machine de la CI et envoyé à Accessia. Adaptez les commandes de construction et de lancement à votre projet :

name: Accessibilité
on: pull_request

jobs:
  accessia:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci && npm run build
      - name: Démarrer le site
        run: npm start & npx -y wait-on http://localhost:3000
      - name: Audit Accessia
        run: >
          npx -y accessia audit http://localhost:3000 http://localhost:3000/contact
          --reference accessia-reference.json
        env:
          ACCESSIA_API_KEY: ${{ secrets.ACCESSIA_API_KEY }}

Adopter la vérification sur un site existant : la référence

Un site existant a souvent déjà des non-conformités. Pour ne bloquer que les nouvelles :

1. Enregistrez l'état actuel : npx accessia audit <vos pages> --ecrire-reference accessia-reference.json, puis ajoutez ce fichier au dépôt.
2. Dans la CI, ajoutez --reference accessia-reference.json : un critère non conforme absent de la référence, ou avec plus d'éléments en cause, fait échouer la vérification ; les critères déjà connus sont signalés sans bloquer.
3. Après des corrections, l'outil signale les critères qui ne sont plus détectés : réécrivez la référence pour verrouiller le progrès.

Options

• --max-non-conformes <n> : non-conformités tolérées (critères × pages) avant l'échec ; 0 par défaut.
• --reference <fichier> et --ecrire-reference <fichier> : voir ci-dessus.
• --navigateur : rendu dans un vrai navigateur (contraste réel, focus, affichage à 320 px), pour les adresses publiques ; offres Pro et Équipe, ou compte avec des crédits (2 crédits par page).
• --referentiel wcag_2.2 (ou wcag_2.1) : vérifier selon les WCAG plutôt que le RGAA 4.1.2.
• --json <fichier> : écrit le résultat complet pour d'autres outils.

Limites, en toute franchise

• Un audit automatique ne couvre qu'une partie du RGAA : une vérification réussie ne prouve pas la conformité.
• Sur une page locale, le code est analysé tel que le serveur le renvoie, avant l'exécution des scripts : le contraste réel, le focus et l'affichage ne sont pas mesurés.
• La référence compare les critères et leur nombre d'éléments, page par page : une erreur remplacée par une autre sur le même critère, au même nombre, n'est pas signalée comme nouvelle.
• 20 pages au plus par lancement.

Le paquet est publié sur npm (nouvelle fenêtre). Pour corriger depuis votre éditeur de code, voir le serveur MCP ; pour lire un rapport, Lire un rapport.