Un défaut nouveau et prouvé
Une image sans alternative, un champ sans étiquette : la machine le prouve, l’équipe sait quoi corriger.
- Défauts prouvés par une règle déterministe
- Comparés à la page auditée au même chemin
- Élément et test RGAA indiqués
Guide · intégration continue
Bloquez un déploiement sur de nouveaux défauts prouvés, jamais sur un score.
Le contrôle mesure vos pages de prévisualisation avec le moteur des audits et les compare à un audit de référence. Il échoue uniquement si la machine prouve un défaut que l’audit ne connaissait pas.
Pourquoi pas un score
Un signal objectif, actionnable et honnête.
La majorité des critères RGAA demandent une personne : un pourcentage calculé par une machine ressemble à un taux de conformité sans en être un.
Un doute ou un défaut connu
Ce que la machine ne peut pas conclure reste pour une personne ; ce que l’audit connaît déjà est suivi ailleurs.
- Les points « à confirmer par une personne »
- Les défauts déjà relevés par l’audit
- Un seuil de score, quel qu’il soit
La conformité
Réussir le contrôle signifie seulement que la machine ne prouve aucun nouveau défaut sur ces pages.
- Les contrôles humains restent nécessaires
- Le taux officiel vient d’un audit finalisé
- Toujours avec son mode d’évaluation
Mise en place
Un script sans dépendance, un code de sortie clair.
Le script agence-rgaa-ci.mjs (Node.js 18 ou plus) lance le contrôle, attend le résultat et affiche les nouveaux défauts prouvés, page par page.
- Code 0 : aucun nouveau défaut prouvé
- Code 1 : nouveaux défauts prouvés, le déploiement s’arrête
- Code 2 : erreur (clé, quota, pages injoignables)
Résultat dans la chaîne (exemple fictif)
Contrôle ck_8f2… : 2 page(s) en file d'attente…
✓ https://preview-42.example.fr/ (comparée à la page auditée) : 0 nouveau(x) défaut(s) prouvé(s)
✗ https://preview-42.example.fr/contact (comparée à la page auditée) : 1 nouveau(x) défaut(s) prouvé(s)
RGAA 11.1.1 #newsletter-email Champ de formulaire sans étiquette
Échec : 1 nouveau(x) défaut(s) prouvé(s).Exemples
À copier dans votre dépôt.
Rangez la clé dans les secrets et l’identifiant de l’audit de référence dans les variables du projet.
GitHub Actions
.github/workflowsÀ chaque demande de fusion, sur les pages de la prévisualisation :
rgaa.yml
name: Accessibilité RGAA
on: [pull_request]
jobs:
rgaa:
runs-on: ubuntu-latest
steps:
- uses: actions/setup-node@v4
with:
node-version: 22
- name: Contrôle Agence RGAA
env:
AGENCE_RGAA_KEY: ${{ secrets.AGENCE_RGAA_KEY }}
run: |
curl -fsSLo agence-rgaa-ci.mjs https://agence-rgaa.fr/integrations/agence-rgaa-ci.mjs
node agence-rgaa-ci.mjs --api https://agence-rgaa.fr \
--audit ${{ vars.AGENCE_RGAA_AUDIT }} \
--url https://preview-${{ github.event.number }}.example.fr/ \
--url https://preview-${{ github.event.number }}.example.fr/contactGitLab CI
.gitlab-ci.ymlUne tâche dans votre pipeline, avec l’adresse de prévisualisation en variable :
.gitlab-ci.yml
rgaa:
image: node:22-alpine
script:
- wget -qO agence-rgaa-ci.mjs https://agence-rgaa.fr/integrations/agence-rgaa-ci.mjs
- node agence-rgaa-ci.mjs --api https://agence-rgaa.fr --audit "$AGENCE_RGAA_AUDIT" --url "$PREVIEW_URL"
# AGENCE_RGAA_KEY : variable CI/CD masquée du projet.Bon à savoir
Avant d’activer le contrôle.
20 pages par contrôle
Chaque page compte comme une revérification dans le quota mensuel de l’organisation.
Comparaison par chemin
/contact est comparée à /contact ; une page absente de l’audit est entièrement nouvelle.
Pages publiques
Les pages doivent être accessibles publiquement : aucune adresse privée ni réseau interne n’est mesuré.
Utilisé avec l’API ou le serveur MCP.
Créer ma cléLe contrôle s’appuie sur POST /ci/checks puis GET /ci/checks/:id (guide de l’API). Vos développeurs peuvent aussi faire revérifier une correction depuis leur assistant.