axe DevTools : intégrer l'accessibilité au flux de développement
axe est devenu le moteur de référence des équipes techniques, moins par ses fonctionnalités que par sa philosophie : ne signaler que ce dont il est certain. Ses règles sont conçues pour produire très peu de faux positifs, ce qui en fait un outil qu'on peut brancher sur une chaîne d'intégration continue sans bloquer les livraisons pour rien.
Trois formes, trois usages
| Forme | Qui s'en sert | Quand |
|---|---|---|
| Extension de navigateur | Développeurs, intégrateurs | Pendant le développement d'un composant |
| Bibliothèque de test | Équipes de test | Dans les tests automatisés, à chaque exécution |
| Intégration continue | Chaîne de production | À chaque proposition de modification |
Sa vraie valeur : la non-régression
L'intérêt principal d'axe n'est pas de découvrir des problèmes — un audit le fait mieux. C'est d'empêcher les régressions. Une conformité obtenue puis non surveillée se dégrade en quelques mises en production ; un test automatisé qui échoue au moment de la modification coûte quelques minutes, là où la même anomalie découverte six mois plus tard au contre-audit coûte un cycle complet.
Configurer axe pour faire échouer la construction, et non pour produire un avertissement. Un rapport que personne n'est obligé de lire n'est jamais lu. C'est le seul moyen d'ancrer l'accessibilité dans la définition de terminé.
Ce qu'il ne verra jamais
axe couvre la part mécanique du référentiel — de l'ordre d'un tiers des manquements dans le meilleur des cas. Il ne juge pas la pertinence d'une alternative textuelle, la cohérence d'un plan de titres, la logique d'un ordre de tabulation, ni la clarté d'un message d'erreur. Sa sobriété en faux positifs a une contrepartie : il se tait sur tout ce dont il n'est pas certain.
Un test axe qui passe ne dit donc rien de la conformité. Voir le calcul du taux de conformité.
Mise en place raisonnable
- Installer l'extension chez les développeurs, et l'utiliser composant par composant.
- Ajouter la bibliothèque aux tests de bout en bout existants, sur les parcours critiques.
- Brancher la vérification sur la chaîne d'intégration, en mode bloquant.
- Compléter par un contrôle manuel au clavier à chaque nouveau composant d'interface.
Ce dernier point n'est pas négociable : c'est lui qui rattrape ce qu'aucun outil ne voit. Voir les tests au lecteur d'écran.
Poursuivre
Pour le signalement visuel sur la page, voyez WAVE. Pour l'audit intégré au navigateur et ce que vaut son score, Lighthouse.