Pourquoi les scanners d'accessibilité ne détectent que 30% des problèmes

Si vous utilisez un scanner d'accessibilité classique pour tester votre site, vous pensez peut-être que "0 erreurs" signifie "site accessible". C'est faux. Ces outils ne détectent que 20 à 30% des critères WCAG.

Le chiffre qui fait réfléchir

Des études indépendantes montrent que les outils automatisés ne peuvent tester que 30 à 40% des Success Criteria WCAG 2.1. Et parmi ceux qu'ils testent, ils ne détectent pas tous les cas.

Le chercheur Eyal Eshet a analysé les résultats de plusieurs outils automatisés sur un échantillon de sites réels et a trouvé un taux de détection effectif de 20 à 25% des problèmes d'accessibilité.

Pourquoi si peu ?

Les scanners font de l'analyse statique du DOM

Un scanner classique inspecte le code HTML de la page au moment de son chargement. Il peut vérifier :

La présence de l'attribut alt sur les images
Le contraste des couleurs entre texte et arrière-plan
La présence de l'attribut lang sur la balise <html>
Les rôles ARIA mal utilisés
Les formulaires sans label

Ce qu'ils NE PEUVENT PAS faire

1. Tester la navigation clavier

Un scanner ne presse pas la touche Tab. Il ne sait pas si un utilisateur peut atteindre tous les éléments interactifs, si le focus est visible, ou s'il existe un piège clavier. Pourtant, les critères RGAA 7.3, 10.7, 12.8 et 12.9 concernent exactement cela.

Critère 12.9 — Piège au clavier
Un scanner voit : <div tabindex="0" onkeydown="...">
Le scanner dit : ✅ Pas d'erreur
La réalité : l'utilisateur est piégé, Tab ne sort jamais de ce composant

2. Tester les composants interactifs

Les menus, modales, accordéons et onglets ARIA doivent respecter les APG Design Patterns :

Un menu doit s'ouvrir avec Enter, se naviguer avec les flèches, et se fermer avec Escape
Une modale doit piéger le focus et le restaurer à la fermeture
Des onglets doivent se naviguer avec les flèches gauche/droite

Un scanner ne clique pas, n'appuie pas sur Enter, ne vérifie pas que Escape ferme la modale. Il vérifie seulement que role="dialog" est présent — pas qu'il fonctionne.

3. Vérifier le focus visible

Le critère 10.7 exige que chaque élément interactif ait un indicateur visuel de focus. Un scanner peut détecter outline: none dans le CSS, mais il ne peut pas vérifier :

Si un box-shadow ou border compense la suppression du outline
Si le pseudo-sélecteur :focus-visible est utilisé
Si le style de focus a un contraste suffisant avec l'arrière-plan

4. Tester le reflow et le zoom

Le critère 10.11 exige que le contenu reste lisible à 320px de large. Le critère 10.4 exige que le zoom à 200% ne cause pas de perte d'information. Un scanner ne redimensionne pas la fenêtre.

5. Évaluer la pertinence

Un scanner peut vérifier qu'une image a un alt. Il ne peut pas vérifier que ce alt est pertinent. alt="image" est techniquement présent mais totalement inutile.

Ce que fait Scrutia différemment

Scrutia va au-delà de l'analyse statique en réalisant des tests dynamiques réels sur votre page :

Navigation clavier réelle

Scrutia simule un parcours Tab complet sur votre page et vérifie que chaque élément interactif est atteignable, que le focus est visible, et qu'aucun piège clavier n'empêche la progression.

Test des composants ARIA

Les menus, modales, onglets et accordéons sont testés selon les APG Design Patterns du W3C : ouverture, fermeture, navigation interne au clavier.

Test du reflow et du zoom

Scrutia vérifie que le contenu reste lisible et fonctionnel en conditions de zoom et de largeur réduite, conformément aux critères WCAG sur le reflow et l'espacement du texte.

Conclusion

Un audit d'accessibilité qui ne teste que le DOM statique passe à côté de 70% des problèmes. Les critères les plus critiques — navigation clavier, composants interactifs, focus visible — nécessitent des tests dynamiques. C'est la raison pour laquelle les audits humains restent indispensables, et c'est ce que Scrutia automatise.