« Automated testing can find on average 57% of WCAG issues automatically. » Cette phrase, présente dans la documentation de Deque Systems, l’éditeur d’axe-core, mérite d’être lue attentivement par toute équipe qui construit son plan de conformité autour d’un seul outil automatisé. Un score vert dans un rapport axe-core ne signifie pas qu’un site est accessible : il signifie qu’aucun des problèmes détectables automatiquement n’a été trouvé, ce qui est une affirmation nettement plus modeste.
Sur un projet de refonte d’un site de collectivité, où l’obligation légale de conformité RGAA impose un niveau d’exigence réel, plusieurs antipatterns liés à une confiance excessive dans axe-core sont apparus. Cet article ne couvre pas la configuration technique d’axe-core elle-même, déjà traitée ailleurs, mais ce que son usage seul laisse passer.
Antipattern : traiter un rapport vert comme un certificat de conformité
Ce qu’on voit : une équipe intègre axe-core dans sa CI, configure l’échec du build sur toute violation détectée, et communique en interne un site « conforme accessibilité » dès que la CI passe au vert pendant plusieurs semaines consécutives.
Pourquoi c’est un problème : axe-core vérifie des règles structurelles et techniques — contraste de couleur calculable, présence d’un attribut alt, structure de landmarks ARIA, ordre de tabulation cohérent avec l’ordre du DOM. Il ne peut pas juger si le texte alternatif d’une image décrit réellement son contenu, si l’ordre de lecture a un sens pour un utilisateur de lecteur d’écran, ou si un parcours de formulaire reste compréhensible dans son ensemble.
Quoi faire : documenter explicitement, dans le rapport de conformité, que la couverture automatisée traite une portion mesurable des critères, et prévoir une session de test manuel avec un lecteur d’écran réel sur les parcours critiques (prise de rendez-vous, dépôt d’une demande, paiement d’une redevance).
Antipattern : ignorer les textes alternatifs vides mais présents
Ce qu’on voit : toutes les images du site portent un attribut alt non vide, ce qui satisfait la règle image-alt d’axe-core sans aucune violation signalée.
Pourquoi c’est un problème : un attribut alt="image" ou alt="photo_2847.jpg" passe la règle automatique tout en étant totalement inutile pour une personne malvoyante. axe-core vérifie la présence d’un texte alternatif, pas sa pertinence sémantique par rapport au contenu réel de l’image.
Quoi faire : ajouter une revue manuelle ciblée sur un échantillon d’images représentatif de chaque type de contenu du site (photos d’actualité, pictogrammes de services, images décoratives correctement marquées comme telles avec alt=""), plutôt qu’une vérification exhaustive de chaque image du site.
Antipattern : valider un formulaire sans tester la navigation clavier réelle
Ce qu’on voit : un formulaire de prise de rendez-vous passe sans violation axe-core sur les attributs label, aria-required et l’ordre du DOM, ce qui rassure l’équipe sur son accessibilité.
Pourquoi c’est un problème : axe-core ne simule pas une vraie navigation au clavier avec la touche tabulation, il analyse la structure statique du DOM. Un piège au clavier provoqué par une bibliothèque JavaScript tierce de sélection de date, qui capture le focus sans offrir de sortie, ne remonte dans aucune règle axe-core standard.
- Naviguer le formulaire entier au clavier, sans souris, du premier au dernier champ
- Vérifier que chaque élément interactif reçoit un focus visible distinct
- Vérifier la possibilité de sortir de tout composant qui capture temporairement le focus
Quoi faire : ajouter un test Playwright dédié qui simule une navigation clavier complète du parcours critique, en complément du contrôle axe-core, plutôt que de considérer l’absence de violation automatique comme suffisante.
Antipattern : exécuter axe-core uniquement sur la page d’accueil
Ce qu’on voit : le test d’intégration continue exécute axe-core sur une unique URL, la page d’accueil, considérée comme représentative de l’ensemble du site.
Pourquoi c’est un problème : un site de collectivité combine des gabarits très différents — page d’accueil, fiche d’annuaire des services, formulaire de démarche en ligne, page d’actualité avec pièce jointe PDF — dont les problèmes d’accessibilité ne se recoupent que partiellement. Un composant défaillant présent uniquement sur le gabarit de formulaire échappe totalement à un test limité à la page d’accueil.
Quoi faire : exécuter axe-core sur un jeu représentatif de gabarits, un par type de page significatif, plutôt que sur une seule URL choisie par commodité.
const gabarits = ['/', '/annuaire/exemple/', '/demarches/rendez-vous/', '/actualites/exemple/'];
for (const url of gabarits) {
test(`axe-core sur ${url}`, async ({ page }) => {
await page.goto(url);
const resultats = await new AxeBuilder({ page }).analyze();
expect(resultats.violations).toEqual([]);
});
}
Antipattern : traiter chaque violation avec la même urgence
Ce qu’on voit : le pipeline échoue de la même façon, qu’axe-core signale un contraste de couleur légèrement insuffisant sur un lien secondaire ou l’absence totale de label sur un champ obligatoire d’un formulaire de paiement.
Pourquoi c’est un problème : traiter toutes les violations avec la même sévérité pousse souvent les équipes, sous pression de délai, à désactiver purement et simplement la règle la plus fréquente plutôt que de la corriger, ce qui fait disparaître un signal utile en même temps que le bruit.
Quoi faire : classer les violations par impact réel sur le parcours utilisateur, en s’appuyant sur le niveau de sévérité déjà fourni par axe-core (critical, serious, moderate, minor), et réserver l’échec bloquant de la CI aux deux premiers niveaux sur les parcours identifiés comme critiques.
Un outil qui détecte 57 % des problèmes n’est pas un mauvais outil : c’est un outil dont il faut connaître précisément la moitié qu’il ne voit pas, pour savoir où porter l’effort humain restant.
En résumé
axe-core reste un filet de sécurité précieux contre les régressions structurelles évidentes, mais aucun de ces antipatterns ne se corrige en changeant sa configuration : ils se corrigent en acceptant que la conformité RGAA d’un site de collectivité exige une vérification manuelle ciblée sur les parcours critiques, en complément d’une automatisation bien calibrée plutôt qu’aveuglément étendue.
