npx axe http://localhost:8080/contact --exit : cette seule commande suffit à faire échouer un pipeline si un formulaire public de collectivité viole une règle d’accessibilité automatiquement détectable. Sur un site municipal ou départemental, cette obligation n’est pas qu’une bonne pratique : le RGAA (référentiel général d’amélioration de l’accessibilité) s’impose légalement aux services publics.
axe-core, la bibliothèque open source développée par Deque Systems, ne remplace pas un audit manuel complet mené par un expert accessibilité : elle détecte automatiquement une partie des violations, essentiellement structurelles et attribuables au balisage. Ce billet montre comment l’intégrer au pipeline CI pour attraper les régressions les plus flagrantes avant qu’elles n’atteignent la production, sans prétendre remplacer l’audit manuel complet, traité dans la catégorie accessibilité.
Ce qu’axe-core détecte, et ce qu’il ne détecte pas
axe-core analyse le DOM rendu et vérifie des règles précises : contraste de couleur insuffisant, champ de formulaire sans label associé, attribut alt manquant sur une image, ordre de tabulation incohérent avec des attributs tabindex positifs. En revanche, il ne peut pas juger de la pertinence d’un texte alternatif, ni de la cohérence logique d’un parcours de navigation au clavier : ces points restent du ressort de l’audit humain.
Installer axe-core dans un projet de tests Playwright
Sur un projet WordPress qui utilise déjà Playwright pour ses tests bout en bout, l’intégration passe par le paquet @axe-core/playwright, qui injecte axe-core dans la page testée et retourne un rapport structuré.
npm install --save-dev @axe-core/playwright
Écrire le test d’accessibilité du formulaire de contact
Le test charge la page du formulaire public, attend son chargement complet, puis lance l’analyse axe-core et vérifie qu’aucune violation critique n’est remontée.
const { test, expect } = require('@playwright/test');
const AxeBuilder = require('@axe-core/playwright').default;
test('le formulaire de contact ne contient aucune violation critique', async ({ page }) => {
await page.goto('/contact/');
const resultats = await new AxeBuilder({ page })
.withTags(['wcag2a', 'wcag2aa'])
.analyze();
const critiques = resultats.violations.filter(v => v.impact === 'critical');
expect(critiques).toEqual([]);
});Filtrer sur les tags wcag2a et wcag2aa permet de rester aligné sur le niveau AA exigé par le RGAA, sans remonter des règles expérimentales qui n’ont pas encore de correspondance officielle dans le référentiel français.
Décider quel niveau de sévérité bloque le merge
axe-core classe chaque violation selon quatre niveaux : critique, sérieux, modéré, mineur. Bloquer le merge sur toute violation, y compris mineure, générerait trop de faux positifs et finirait par décourager l’équipe de traiter les alertes sérieusement.
- Violation critique ou sérieuse sur un formulaire public : le pipeline échoue
- Violation modérée : avertissement visible, mais le merge reste possible
- Violation mineure : consignée dans un rapport de suivi, revue périodique
Étendre le contrôle aux autres formulaires publics
Une fois le formulaire de contact couvert, le même test se généralise facilement aux autres points d’entrée publics : formulaire de demande de rendez-vous, formulaire d’inscription à une newsletter municipale, formulaire de signalement de voirie.
Intégrer le contrôle au pipeline CI existant
L’étape axe-core s’ajoute comme une tâche supplémentaire après le déploiement de l’environnement de prévisualisation, dans le même job que les autres tests Playwright déjà en place.
- Démarrer un environnement WordPress éphémère avec les données de test
- Lancer la suite Playwright incluant les tests axe-core
- Publier le rapport de violations comme artefact du pipeline, consultable par l’équipe
Sur un site de collectivité, on a pris l’habitude de traiter toute violation critique remontée par axe-core comme un bug bloquant au même titre qu’une erreur PHP fatale : la loi ne fait pas de distinction de priorité.
En résumé
Intégrer axe-core au pipeline CI d’un site de collectivité permet de rattraper automatiquement une bonne part des régressions d’accessibilité les plus visibles sur les formulaires publics, à chaque merge. Ce contrôle reste un filet de sécurité technique, complémentaire à l’audit manuel complet qui seul peut juger de la pertinence réelle du contenu et du parcours utilisateur.
