Tu lances un scan automatique sur ton site. L'outil remonte 12 erreurs, un score de 78 sur 100. La tentation est de penser que le reste est réglé. Ce n'est pas le cas.
Les outils de test automatique - axe-core, Lighthouse (qui intègre axe-core en interne), WAVE et leurs équivalents - sont utiles. Ils détectent vite, sans effort, un ensemble réel de problèmes. Mais leur couverture a des limites documentées. Les connaître, c'est la condition pour interpréter un rapport de scan correctement.
Deux façons de mesurer la couverture
Deque, l'éditeur d'axe-core, a publié une étude basée sur plus de 2 000 audits menés sur 13 000 pages et près de 300 000 problèmes identifiés (Deque, "Automated Testing Study Identifies 57% of Digital Accessibility Issues"). C'est une auto-publication d'éditeur, non revue par les pairs, à lire en tenant compte de ce biais. Le chiffre avancé : les outils automatiques de la suite axe détectent 57 % des problèmes d'accessibilité, mesurés par volume d'occurrences.
Ce chiffre est souvent cité à l'avantage des outils automatiques. Il mérite d'être contextualisé.
La mesure qui compte pour la conformité RGAA est différente : combien de critères de succès WCAG peuvent être vérifiés de façon fiable par un outil automatique ? Ce nombre est nettement inférieur à 57 %. La raison est simple : la mesure en volume gonfle le score. Une image sans attribut alt sur une page en génère une occurrence par image - parfois des dizaines pour le même défaut. La mesure par critères est binaire : soit le test peut être automatisé, soit il ne peut pas.
Pour la conformité RGAA, c'est la seconde mesure qui importe. Le W3C note que les outils automatiques « ne peuvent pas déterminer la conformité » et que leur rôle est d'identifier des problèmes, pas de certifier leur absence (W3C WAI, Evaluating Web Accessibility Overview).
Ce qu'axe-core détecte bien
Les outils automatiques sont efficaces sur les problèmes structurels et syntaxiques. Ils repèrent :
- Les attributs
altabsents sur les images (<img>sansaltni équivalent accessible) - Les contrastes de couleur insuffisants entre texte et arrière-plan (sur fond uni - les dégradés et images de fond génèrent souvent un résultat
incomplete, non conclusif) - Les éléments de formulaire sans étiquette associée (
<input>sans<label>) - Les erreurs ARIA manifestes : rôles invalides, attributs requis absents
- Les liens sans texte visible et sans alternative
- Les pages sans titre
<title> - La langue de la page non déclarée dans
<html lang=""> - Les valeurs
tabindexpositives (> 0), anti-pattern qui perturbe l'ordre naturel de navigation
Ce sont des erreurs réelles, fréquentes, et leur correction améliore l'accessibilité.
Ce qu'axe-core ne peut pas évaluer
La liste des critères RGAA 4.1.2 qui ne peuvent pas être testés automatiquement est longue. Voici les catégories principales.
La pertinence des alternatives textuelles. Axe-core détecte une image sans alt. Il ne peut pas juger si l'alt fourni est pertinent. Une image d'un graphique de ventes avec alt="image" passe le test automatique. Elle échoue au critère 1.3 du RGAA, qui exige que l'alternative textuelle soit pertinente - là où le critère 1.1 se contente de vérifier sa présence. Voir la fiche alternative textuelle non pertinente.
Les images décoratives. axe-core passe systématiquement une image avec alt="", role="presentation" ou role="none". Ces marquages sont valides pour une image décorative - mais l'outil ne peut pas juger si une image est réellement décorative. Un schéma d'architecture avec alt="" passe le scan et échoue au critère 1.2 du RGAA. Voir la fiche image décorative non ignorée.
La sémantique des titres. axe-core vérifie qu'un <h1> est présent et que la hiérarchie ne saute pas de niveau (h1 → h3 sans h2 intermédiaire). Ce qu'il ne peut pas vérifier : si les titres reflètent réellement le découpage éditorial, si un h2 permet de comprendre le sujet de la section sans lire le corps. La fiche hierarchie-titres-incorrecte distingue ce qui est détectable mécaniquement de ce qui requiert un oeil humain.
La navigabilité au clavier et l'ordre de focus. Un scanner peut détecter un tabindex positif ou un élément non focusable via une règle CSS. Il ne peut pas parcourir la page comme un utilisateur de clavier et vérifier que l'ordre de focus est logique, que les modales sont attrapables, que les sous-menus se ferment au bon moment. Voir les fiches élément non contrôlable au clavier et ordre de tabulation incohérent.
Les formulaires et les messages d'erreur. Un champ sans étiquette est détectable. En revanche, la pertinence de l'étiquette, la clarté du message d'erreur après soumission, ou la gestion du focus après une erreur de validation nécessitent un test humain. Voir la fiche étiquette de formulaire non pertinente.
Le comportement des composants dynamiques. Les carrousels, les menus déroulants, les onglets, les dialogues modaux : leur accessibilité dépend de l'interaction dans le temps, de l'état après un clic, du comportement après une frappe clavier. Un scan prend un instantané statique. La fiche script non compatible avec les technologies d'assistance couvre ce que les tests dynamiques cherchent à détecter.
La restitution par les lecteurs d'écran. Ce que le DOM annonce comme accessible et ce qu'un lecteur d'écran comme NVDA, JAWS ou VoiceOver restitue réellement à l'utilisateur sont deux choses différentes. Les bugs d'interopérabilité ne sont visibles qu'en test manuel avec une technologie d'assistance.
Pourquoi ça compte pour l'EAA
Depuis le 28 juin 2025, les services listés par la directive (UE) 2019/882 - e-commerce, banque en ligne, livraison de contenus numériques, transports - sont soumis aux exigences d'accessibilité. L'exemption microentreprise s'applique uniquement aux entités réunissant à la fois moins de 10 salariés et un chiffre d'affaires annuel ou un total de bilan n'excédant pas 2 millions d'euros. Une structure de 8 personnes à 2,5 M€ de CA, ou de 15 personnes à 1,8 M€, reste dans le périmètre.
La conformité s'évalue critère par critère, sur la base d'un audit réel. Un scan automatique seul ne constitue pas un audit. Il ne produit pas de taux de conformité RGAA. Il ne suffit pas à rédiger une déclaration d'accessibilité sincère : celle-ci doit mentionner la méthodologie utilisée et le taux de conformité aux critères applicables, ce que seul un audit réel peut établir.
La DGCCRF contrôle les PME dans le cadre de ses enquêtes EAA en cours. En cas de contrôle, une déclaration d'accessibilité doit pouvoir être étayée par un audit documenté.
Les overlays d'accessibilité tombent dans le même piège : ils corrigent automatiquement une fraction des problèmes détectables mécaniquement, sans toucher aux critères qui nécessitent du jugement humain. Nous l'avons détaillé dans notre article sur les overlays.
La bonne démarche
Un audit complet combine trois niveaux :
- Le scan automatique : détection rapide des erreurs structurelles et syntaxiques. Point de départ obligatoire, pas point d'arrivée.
- Les tests manuels : navigation au clavier page par page, vérification de la pertinence des alternatives, test des formulaires et des composants dynamiques.
- Les tests avec un lecteur d'écran : NVDA ou JAWS sur Windows, VoiceOver sur macOS/iOS. Ce niveau conditionne certains critères RGAA qui portent explicitement sur la restitution par les technologies d'assistance - les passer sans ce test revient à les laisser en "non testé".
La checklist de conformité EAA couvre les cinq étapes de la démarche complète, avec les documents à produire.
Ce que Mynto fait
L'audit automatique Mynto repose sur axe-core et sur des détections propres à nos huit axes d'analyse. Il détecte les erreurs accessibles à un outil de scan - et seulement celles-là.
Nous ne promettons pas de conformité automatique. Nous ne prétendons pas qu'un score Mynto de 90 signifie que ton site respecte 90 % des critères RGAA. Ce que nous faisons : repérer vite les problèmes que tu peux corriger maintenant, et te montrer clairement ce qui nécessite un test humain complémentaire.
Un scan est un état des lieux, pas un certificat.
Sources
- Deque, "Automated Testing Study Identifies 57% of Digital Accessibility Issues" - étude auto-publiée par l'éditeur d'axe-core sur 2 000+ audits, 13 000+ pages
- W3C WAI, Evaluating Web Accessibility Overview - méthodes de test, rôle et limites de l'automatisation
- W3C, Accessibility Conformance Testing (ACT) Overview - cadre de tests de conformité (automatique, semi-automatique, manuel)
- RGAA 4.1.2, critères et tests - référentiel officiel
À lire aussi
Où en est ton site sur ce sujet ?
Lance un audit Mynto gratuit. SEO, performance, accessibilité, conformité : tu sais en quelques minutes ce qui bloque et ce que ça coûte.