Quelle part des défauts d'accessibilité trouvés en audit manuel ou signalés par des utilisateurs avait passé les contrôles automatisés en CI, et quels types de défauts leur ont échappé ?

Question ouverte

Les vérificateurs d'accessibilité automatisés sont peu coûteux à exécuter : un moteur de règles inspecte le DOM rendu à chaque build et fait échouer le pipeline en cas de texte alternatif manquant, de contraste faible, de contrôles de formulaire sans étiquette ou d'attributs ARIA invalides. Les recommandations du W3C WAI sur le choix des outils d'évaluation indiquent explicitement que les outils font gagner du temps mais ne peuvent pas tout faire, car certains contrôles d'accessibilité ne peuvent pas être automatisés et nécessitent une intervention manuelle. La tentation est néanmoins de considérer une exécution automatisée au vert comme signifiant « accessibilité acquise », car un audit manuel coûte de l'argent et les signalements d'utilisateurs arrivent par les canaux de support plutôt que par le build.

Ce qui manque au wiki, c'est un relevé de cet écart sur des sites réels. Lorsqu'un audit manuel (une revue d'expert avec un lecteur d'écran et le clavier, ou une session avec des utilisateurs en situation de handicap) a été mené sur un site dont les builds passaient déjà un vérificateur automatisé, quelle part des défauts trouvés était présente dans les pages contrôlées et était tout de même passée au travers ? Quels types de défauts dominent cette part : ordre de focus et perte de focus, pièges au clavier dans des widgets personnalisés, texte de lien dénué de sens mais techniquement étiqueté, ordre de lecture erroné, messages d'état jamais annoncés, texte alternatif présent mais incorrect, mouvement impossible à mettre en pause ? Et l'inverse : quelle part des constats automatisés s'est révélée sans pertinence pour aucun utilisateur du site, au point que l'équipe a appris à ignorer l'outil ? L'écart se réduit-il lorsque l'exécution automatisée inclut une interaction au clavier scriptée, ou lorsque la bibliothèque de composants a elle-même été auditée, de sorte que les défauts restants résident dans la composition des pages plutôt que dans les composants ?

La réponse détermine où doit porter l'effort d'accessibilité limité d'une petite équipe : davantage de règles en intégration continue, une passe manuelle périodique, ou un audit du système de design.

Ce qu'une réponse utile contient

Le type de site, le framework et la bibliothèque de composants, ainsi que le vérificateur avec son jeu de règles et sa version. Le nombre de pages couvertes par l'exécution automatisée et par l'audit manuel. Pour chaque défaut trouvé manuellement ou signalé par un utilisateur : le critère de succès concerné, si la page avait passé l'exécution automatisée, et si une règle existe dans l'outil pour ce défaut mais ne s'est pas déclenchée. Pour chaque constat automatisé sur la même période : s'il a été corrigé, supprimé ou jugé faux positif, avec la raison. La méthode d'audit (revue d'expert, test avec une technologie d'assistance, session utilisateur), chacune trouvant des choses différentes. Si l'équipe a changé quoi que ce soit en conséquence : ajout de règles, ajout d'une liste de contrôle manuelle à la revue, ou remplacement de composants. Les rapports portant sur un seul site sont bienvenus si le jeu de règles et la méthode d'audit sont précisés ; les comparaisons entre sites utilisant le même outil sont plus utiles.