Audit accessibilité réel : ce qu’on teste vraiment, et ce que les outils ratent

Un outil automatique vérifie des règles observables : présence d’un attribut, contraste calculable, structure de titres, nom accessible, référence ARIA cassée, champ sans label, image sans alternative. Cette couche est indispensable parce qu’elle industrialise les alertes et évite de perdre du temps sur les erreurs faciles.

Mais l’accessibilité réelle dépend aussi de relations, d’intentions et de scénarios. Un lien peut avoir un nom et rester incompréhensible. Un bouton peut être détecté et déclencher une interaction impossible à fermer. Un formulaire peut avoir des labels et perdre des contacts parce que ses erreurs arrivent trop tard, trop bas dans la page ou sans lien avec le champ concerné.

Les chiffres varient parce que tout dépend de ce que l’on compte : critères WCAG théoriquement automatisables, erreurs détectées sur un échantillon de pages, ou types de problèmes qu’un moteur comme axe sait signaler. L’ordre de grandeur utile pour décider est le suivant : les approches automatiques couvrent une partie du risque, souvent autour d’un tiers à un peu plus de la moitié selon la méthode retenue. Elles ne remplacent donc jamais une revue humaine.

C’est aussi la position du W3C/WAI sur les outils d’évaluation : ils aident à détecter certains problèmes, mais ils ne peuvent pas déterminer seuls si un site est accessible. Un audit de référence doit donc afficher clairement ce qui a été automatisé, ce qui a été revu humainement et ce qui reste hors périmètre.

Un rapport sérieux indique les couples testés : par exemple NVDA avec Firefox ou Chrome sur Windows, JAWS avec Chrome ou Edge lorsque le contexte l’exige, VoiceOver avec Safari sur macOS et iOS, et TalkBack avec Chrome sur Android pour les parcours mobiles. Le choix dépend du public, du périmètre, du budget et du risque métier, mais il doit être explicite.

Cette précision évite une ambiguïté fréquente : “testé avec un lecteur d’écran” ne veut pas dire grand-chose si l’on ne sait pas lequel, sur quel navigateur, sur quel système, avec quelle tâche et quelle version.

Un audit utile ne mélange pas tout dans une note finale. Il sépare les couches, puis les relie. C’est cette séparation qui rend les corrections actionnables : on sait si le problème vient du design, du contenu, du composant front-end, du CMS, d’un choix ARIA ou d’un parcours métier mal pensé.

Fermer la souris et utiliser uniquement le clavier révèle très vite la maturité d’une interface. Le focus est-il visible ? Suit-il un ordre logique ? Peut-on ouvrir et fermer le menu ? Le contenu caché devient-il accessible ? Une modale rend-elle le focus à son déclencheur ? Le formulaire annonce-t-il l’erreur au bon moment ?

Ce test est puissant parce qu’il traverse plusieurs dimensions à la fois : code, design, JavaScript, contenu, composants et parcours. Il ne remplace pas un audit RGAA complet, mais il met en lumière des blocages que les scores automatiques laissent souvent passer.

Il ne faut pas promettre qu’un site accessible sera mieux classé ou automatiquement cité par les IA. Ce serait faux. En revanche, beaucoup de signaux audités en accessibilité rendent la page moins ambiguë : titres réels, landmarks, liens descriptifs, boutons nommés, labels reliés, tableaux lisibles, contenu rendu dans le DOM et ordre cohérent. Dans cette grille, 5 des 7 couches servent aussi la lisibilité par les robots et les agents : structure, interactions nommées, formulaires, DOM et preuve.

C’est exactement le pont avec le SEO technique et le GEO : avant de demander à Google, Perplexity, ChatGPT ou un agent de comprendre une page, il faut s’assurer qu’elle peut être lue proprement. Une interface qui cache son sens dans la mise en page, le JavaScript ou des composants non nommés oblige les systèmes à deviner.

Le mouvement devient visible dans les outils eux-mêmes. Le changelog Lighthouse 13.3.0 mentionne l’ajout d’une catégorie agentic browsing avec llms.txt, WebMCP et un audit agent-accessibility-tree. Son libellé est explicite : un arbre d’accessibilité bien formé aide les agents IA à naviguer et interagir avec la page. Ce n’est pas une garantie de citation par une IA ; c’est le signal le plus clair que la lisibilité par les agents rejoint déjà les sujets de structure, d’accès clavier, de noms accessibles et de contenu exploitable.

Après publication locale, la page a été corrigée sur un point exactement lié au sujet : des cartes de vision portaient un role="listitem" alors que le parent perdait son role="list" pendant la normalisation du HTML. La correction supprime le rôle orphelin dans le rendu final. C’est le type de détail qu’un outil peut remonter, et qu’un article sur les limites des outils ne peut pas se permettre d’ignorer.

Cette page peut aussi afficher un score Lighthouse à 100. Selon la thèse de cet article, cela ne prouve rien. Le score reste un signal secondaire : la preuve utile commence quand on cherche ce que Lighthouse ne voit pas, puis quand on documente les corrections.

Contrôle de prépublication du 7 juillet 2026 : axe-core 4.12.1 trouve 0 violation automatique sur les versions française et anglaise après chargement des polices. Le parcours clavier desktop complet, rejoué avec Playwright, compte 54 arrêts uniques, revient au premier focus, et ne contient aucun focus invisible ni sans contour visible. Pendant cette passe, la page a aussi corrigé un contraste de badge et un scroll-behavior: smooth qui pouvait retarder l’arrivée du focus dans le viewport lors des grands sauts.

Limite explicite : cette preuve reste une non-régression de prépublication. Elle doit être relancée sur l’URL canonique après déploiement, avec une toolchain actuelle — la version courante du paquet Lighthouse est 13.4.0 au 7 juillet 2026 — puis complétée par une passe NVDA, JAWS ou VoiceOver sur les parcours critiques.

Pour la méthode complète, la preuve ne flotte pas seule : elle renvoie au rapport d’audit accessibilité Edikka, publié avec grille RGAA 4.1.2, périmètre, résultats, non-conformités et preuves téléchargeables.

Un audit accessibilité qui termine par “100/100” n’aide pas vraiment une équipe à décider. Un audit utile doit permettre de répondre à quatre questions : qu’est-ce qui bloque ? Sur quelle page ? Pour quel utilisateur ou système ? Quelle correction produit le plus d’impact ?

En France, le RGAA 4.1.2 donne un cadre de méthode et de déclaration. RGAA 5 est annoncé pour fin 2026, avec intégration de WCAG 2.2, applis mobiles, documents bureautiques et simplification des critères. Pour les produits et services concernés par l’European Accessibility Act, les obligations sont entrées en application le 28 juin 2025. Le sujet ne concerne donc plus seulement les équipes techniques : il touche la gouvernance, la preuve, les parcours de vente et la relation client.

Mais une déclaration publiée sans méthode claire reste fragile. Elle doit être reliée à un périmètre audité, une date, un état de conformité, des contenus non accessibles, un contact et une voie de recours. L’audit réel donne de la substance à cette déclaration. Il évite les promesses floues et rend les corrections vérifiables.

Toutes les anomalies ne se valent pas. Une alternative d’image imparfaite sur une illustration décorative n’a pas le même impact qu’un menu inaccessible, un bouton sans nom, un formulaire impossible à corriger ou une modale qui piège le focus. La priorisation doit partir de l’usage : quelles erreurs bloquent l’accès à l’information, la demande de contact, l’achat ou la compréhension ?

C’est aussi la meilleure façon de faire accepter l’accessibilité dans une équipe. On ne vend pas une liste abstraite de critères ; on montre où le site perd des utilisateurs, des demandes, de la confiance et de la lisibilité.