Une refonte de thème avait remplacé un menu de navigation accessible au clavier par un composant JavaScript plus moderne visuellement, mais qui piégeait le focus dès qu’un visiteur au clavier y entrait, sans moyen d’en sortir autrement qu’en rechargeant la page. Aucun test fonctionnel classique n’aurait détecté ce problème, puisque la souris permettait de contourner le piège sans jamais s’en apercevoir. Intégrer axe-core dans les tests de bout en bout aurait signalé ce piège au clavier avant la mise en production.
Il faut poser une limite claire dès le départ : les outils automatisés d’accessibilité, aussi bons soient-ils, ne couvrent qu’une fraction des critères WCAG — l’ordre de grandeur généralement admis tourne autour d’un tiers. Contraste insuffisant, attribut alt manquant ou structure de titres incohérente se détectent bien automatiquement ; la pertinence d’un texte alternatif ou la cohérence logique d’un parcours au clavier demandent toujours un test humain.
Intégrer axe-core dans des tests Playwright
npm install --save-dev @axe-core/playwright
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
test('la page produit ne contient pas de violation critique', async ( { page } ) => {
await page.goto( '/boutique/produit-exemple/' );
const resultats = await new AxeBuilder( { page } ).analyze();
const violationsCritiques = resultats.violations.filter(
v => v.impact === 'critical' || v.impact === 'serious'
);
expect( violationsCritiques ).toEqual( [] );
});
Filtrer sur les niveaux d’impact critical et serious permet de bloquer réellement le pipeline sur les problèmes les plus graves, sans faire échouer chaque build sur des remarques mineures qui méritent une revue humaine plutôt qu’un blocage automatique.
Pa11y CI pour balayer plusieurs gabarits de page
Là où axe-core s’intègre bien à des tests ciblés, Pa11y CI est pensé pour auditer une liste de pages en une seule commande, ce qui convient bien à une vérification rapide de plusieurs gabarits :
npm install --save-dev pa11y-ci
// .pa11yci.json
{
"defaults": {
"standard": "WCAG2AA",
"timeout": 10000
},
"urls": [
"http://localhost:8080/",
"http://localhost:8080/boutique/",
"http://localhost:8080/contact/"
]
}
npx pa11y-ci
Traiter les faux positifs sans désactiver la règle globalement
Un cas fréquent : un widget tiers, comme un lecteur vidéo intégré, génère une alerte de contraste sur des éléments que le projet ne maîtrise pas. Le réflexe à éviter est de désactiver la règle de contraste pour tout le site. La bonne pratique consiste à ignorer précisément le sélecteur concerné :
{
"urls": [
{
"url": "http://localhost:8080/contact/",
"hideElements": ".lecteur-video-tiers"
}
]
}
- Documenter dans le fichier de configuration pourquoi chaque exception existe
- Revoir périodiquement la liste des exceptions : un widget mis à jour peut avoir corrigé le problème entre-temps
- Ne jamais désactiver une règle entière pour tout le site à cause d’un seul composant tiers
Notre verdict
axe-core et Pa11y CI attrapent efficacement une large part des régressions techniques d’accessibilité avant qu’elles n’atteignent la production, à condition de bien cibler les niveaux de sévérité et de documenter chaque exception. Ils ne remplacent en rien un audit manuel avec lecteur d’écran et navigation clavier complète, qui reste indispensable pour les critères que l’automatisation ne peut tout simplement pas juger.
