Intégration de l'accessibilité dans le CI/CD

Le bug d’accessibilité le moins cher est celui qui n’est jamais mergé. L’intégration de l’accessibilité dans le CI/CD déplace les tests vers la gauche, dans votre pipeline de développement, de sorte que les régressions sont détectées automatiquement à chaque pull request au lieu de remonter des mois plus tard dans un audit — ou dans une plainte.

Pourquoi intégrer l’accessibilité dans le CI/CD

La plupart des équipes testent l’accessibilité après coup : un audit périodique produit une longue liste, l’équipe la corrige, puis les mêmes catégories de problèmes réapparaissent discrètement avec les fonctionnalités suivantes. Automatiser les vérifications dans le pipeline brise ce cycle. Chaque modification est évaluée au moment où elle est faite, les développeurs reçoivent un retour pendant que le code est encore frais, et votre conformité durement acquise est protégée contre les régressions silencieuses.

Comment ça fonctionne

La fonctionnalité Code Analysis de QualiBooth s’intègre avec GitHub Actions. Une fois configuré, le workflow s’exécute automatiquement à chaque push et pull request :

1. Installez la GitHub Action QualiBooth et ajoutez votre secret QUALIBOOTH_ORG_UUID.
2. Committez le fichier de workflow — GitHub déclenche alors automatiquement les scans d’accessibilité.
3. Les résultats apparaissent dans le tableau de bord Scan Runs de QualiBooth, consultable par dépôt, branche ou hash de commit.
4. Chaque violation est localisée à un chemin de fichier et un numéro de ligne avec un niveau de sévérité Error ou Warning.
5. Lorsqu’un correctif est intégré, le scan suivant marque le problème comme Corrigé — les progrès sont mesurables exécution par exécution.

L’analyse basée sur ESLint prend actuellement en charge les bases de code React, Vue, JavaScript et TypeScript. La prise en charge de frameworks supplémentaires et de plateformes CI est prévue.

Ce que nous mettons en place

1. Intégration GitHub Action — l’action QualiBooth intégrée dans le workflow de votre dépôt.
2. Retour sur les PR — des vérifications automatiques qui commentent les résultats directement sur les pull requests.
3. Détection des régressions — chaque scan est comparé à une baseline afin que les nouveaux problèmes soient clairement séparés du backlog existant.
4. Références de base — un instantané des problèmes existants pour que vous appliquiez les gates aux nouveaux problèmes, et non à l’ensemble de votre backlog d’un coup.
5. Tableau de bord Scan Runs — chaque exécution enregistrée avec la branche, le commit, le nombre de problèmes et le suivi des problèmes corrigés.

Où les vérifications s’exécutent

• Pull requests — scans rapides des fichiers modifiés pour un retour rapide au relecteur
• Pushes de branche — surveillance continue pour détecter les régressions avant la revue de PR
• Contrôles avant merge — détecter les nouvelles régressions avant qu’elles n’atteignent la branche principale
• Balayages planifiés — scans plus complets, nocturnes ou de release, sur l’ensemble de l’application

Une limite honnête

Les tests automatisés ne détectent de façon fiable que 30 à 40 % des critères de succès des WCAG. Nous sommes explicites à ce sujet : l’intégration CI/CD est la manière dont vous empêchez les problèmes automatisables d’être un jour livrés et dont vous vous protégez contre les régressions — mais elle ne remplace pas le jugement humain. Notre guide sur les tests d’accessibilité automatisés dans le CI/CD détaille où se situe cette limite en pratique. La vision complète vient de la combinaison des gates automatiques avec des audits manuels par des personnes en situation de handicap et des audits récurrents.

À qui cela s’adresse

Aux équipes d’ingénierie et de plateforme qui livrent en continu et veulent que l’accessibilité soit un gate de qualité automatique et standard — au même titre que les tests et le linting. C’est une composante naturelle d’un programme plus large d’amélioration des processus d’accessibilité.