Ce que les tests d’accessibilité automatisés peuvent et ne peuvent pas prouver

Les tests d’accessibilité automatisés peuvent montrer que certaines parties d’une page ne respectent pas des exigences précises : une image n’a pas d’alternative textuelle, un champ de formulaire n’a pas d’étiquette, la page ne déclare pas sa langue, ou un texte a un contraste de couleur inférieur à celui qu’exigent les WCAG. Ils ne peuvent pas prouver la conformité d’une page, ni d’une boutique entière, aux WCAG 2.2 niveau AA.

À propos de ce que les outils ne peuvent pas faire, les conseils du W3C pour choisir des outils d’évaluation de l’accessibilité web indiquent ceci (sur cette page, les citations de sources en anglais sont traduites par nos soins) : « Les outils ne peuvent pas vérifier automatiquement tous les aspects de l’accessibilité. Un jugement humain est nécessaire. Il arrive que les outils d’évaluation produisent des résultats faux ou trompeurs. Les outils d’évaluation de l’accessibilité web ne peuvent pas déterminer l’accessibilité, ils peuvent seulement aider à la déterminer. »

Le W3C prévoit les deux types de tests. Understanding Conformance, qui fait partie des documents Understanding WCAG 2.2 du W3C, indique que tous les critères de succès des WCAG 2 sont rédigés comme des critères testables, et ajoute : « Tester les critères de succès supposerait de combiner des tests automatisés et une évaluation humaine. »

La frontière entre les deux traverse les critères de succès eux-mêmes. Beaucoup demandent à la fois quelque chose qu’un programme peut trouver et quelque chose qu’une personne doit juger. Le critère de succès 1.1.1 demande une alternative textuelle « qui remplit une fonction équivalente ». Voici le texte intégral du critère de succès 2.4.6 : « Les titres et les étiquettes décrivent le sujet ou l’objectif. » Un programme peut trouver l’alternative textuelle, le titre et l’étiquette. Savoir s’ils remplissent leur fonction relève d’un jugement sur le sens.

Un scanner qui repose sur un moteur de règles comme axe-core charge une page dans un navigateur et applique un ensemble de règles à la page telle que le navigateur l’affiche. Chaque règle cherche un type d’échec, par exemple un bouton sans nom accessible, et signale l’élément où elle l’a trouvé.

axe-core, le moteur de règles open source de Deque Systems que le scanner de Validiscan exécute, comporte des règles pour les WCAG 2.0, 2.1 et 2.2 aux niveaux A, AA et AAA, ainsi que des règles de bonne pratique (README d’axe-core). D’après un décompte fait pour ce guide à partir de la liste des règles d’axe-core 4.13.0, 63 règles relèvent des niveaux A et AA des WCAG, sans compter celles que la liste marque comme expérimentales ou obsolètes. Ensemble, ces 63 règles sont rattachées à 20 des 55 critères de succès que les WCAG 2.2 comptent à ces niveaux.

Un scan voit ce qui se trouve sur la page au moment où les règles s’exécutent. La documentation de l’API d’axe-core énumère les étapes d’un test, et la dernière est : « Répéter l’opération pour tout contenu inactif ou non affiché après l’avoir rendu visible ». Un menu, une boîte de dialogue ou un message d’erreur qui n’apparaît qu’après un clic ou l’envoi d’un formulaire n’est testé que si quelque chose l’ouvre d’abord. Certains contrôles interagissent donc avec la page : ils s’y déplacent avec la touche Tab, ou l’affichent sur une largeur étroite, et mesurent ce qui se passe. Les contrôles de ce type propres à Validiscan sont décrits plus bas.

Non. Un échec signalé par une règle est une preuve qu’une exigence n’est pas satisfaite. Une réussite montre seulement que la règle n’a relevé aucun échec du type qu’elle recherche.

Le W3C fait la même distinction pour ses propres règles de test. Les règles ACT décrivent comment tester la conformité aux WCAG et à WAI-ARIA, et une règle ACT peut tester un seul aspect d’une exigence : « une règle ACT pourrait tester qu’une cellule de tableau a un en-tête, plutôt que de tester le critère de succès 1.3.1, Info and Relationships, dans son intégralité ». Lorsqu’un contenu échoue à une règle ACT, il ne satisfait pas à l’exigence correspondante. Lorsqu’il la réussit, « aucun échec correspondant n’a été détecté », ce qui « ne signifie pas nécessairement que le contenu satisfasse à tous les aspects de l’exigence d’accessibilité correspondante ». Les règles ACT ont un caractère informatif : elles ne sont pas requises pour déterminer la conformité aux WCAG.

Le README d’axe-core énonce, parmi ses principes : « Il ne renvoie aucun faux positif (bogues mis à part). » Il ajoute qu’axe-core classe des éléments comme « incomplete » lorsqu’il ne peut pas conclure avec certitude, et qu’une revue manuelle est alors nécessaire. C’est ce que le projet dit de sa propre conception, et non une mesure indépendante, et les conseils du W3C cités plus haut avertissent, à propos des outils d’évaluation en général, qu’ils peuvent produire des résultats faux ou trompeurs. Cette conception montre en tout cas une chose : le nombre d’échecs signalés n’est pas un total. Il compte ce que les règles ont pu établir, pas tout ce qui ne va pas.

Trois règles d’axe-core 4.13.0 montrent où passe la limite :

• Images. La règle sur les images accepte une image qui a un attribut alt ou, parmi quelques autres possibilités, une étiquette ARIA, et le message de réussite de son contrôle est « Element has an alt attribute », soit « l’élément a un attribut alt » (contrôle has-alt). Le contrôle vérifie que l’attribut existe, pas ce qu’il dit. Un alt vide, qui marque une image comme décorative, est accepté lui aussi. Savoir si le texte décrit l’image, et si l’image est vraiment décorative, c’est à une personne d’en juger.
• Sous-titres des vidéos. La règle sur les sous-titres accepte une vidéo qui a une piste de sous-titres. Sans piste, elle ne peut pas conclure à un échec, car, comme le dit un commentaire de son code, « les médias peuvent utiliser une autre méthode de sous-titrage ». Elle renvoie le résultat « à examiner » avec le message « Check that captions are available for the element », soit « vérifier que des sous-titres sont disponibles pour l’élément » (contrôle caption). Juger de l’exactitude des sous-titres est hors de sa portée.
• Contraste des couleurs. Le contrôle du contraste calcule le rapport de contraste entre le texte et son arrière-plan, et il énumère 15 raisons de renvoyer à la place le résultat « à examiner », parmi lesquelles une image d’arrière-plan, un dégradé d’arrière-plan et un élément recouvert par un autre (contrôle color-contrast). Un texte placé sur une image d’arrière-plan, par exemple dans une bannière, passe en « à examiner ».

Selon l’analyse propre à Validiscan, un contrôle automatisé peut trancher la plupart des cas pour quelques critères de succès des WCAG 2.2. Pour la plupart des critères, un contrôle peut établir certains échecs, mais c’est une personne qui décide si le critère est satisfait. Pour environ un tiers, seule une personne peut trancher.

Ce regroupement n’est pas une classification du W3C. Il s’appuie sur le texte de chaque critère de succès des WCAG 2.2, sur les règles ACT du W3C, sur la liste des règles d’axe-core 4.13.0 et sur un document de travail du W3C, Challenges with Accessibility Guidelines Conformance and Testing, and Approaches for Mitigating Them, cité ici comme un travail en cours, ainsi que le document lui-même le demande. Ce document résume ainsi le problème général : « Nous savons tester automatiquement les occurrences d’un balisage pertinent et les compter. En revanche, nous ne savons pas encore vérifier automatiquement la qualité de ce que ce balisage transmet à l’utilisateur. »

Ainsi regroupés, les 55 critères de succès des WCAG 2.2 aux niveaux A et AA se répartissent en trois groupes :

Le regroupement décrit ce qu’un contrôle peut établir en principe. Ce que teste un outil donné est plus restreint et diffère d’un outil à l’autre.

Dans une évaluation complète, les outils assistent et les personnes évaluent. La méthodologie d’évaluation du W3C attribue deux rôles aux outils : aider à repérer un échantillon représentatif, et assister les personnes qui l’évaluent ensuite.

WCAG-EM 2.0, la méthodologie d’évaluation des WCAG (WCAG Evaluation Methodology), que l’Accessibility Guidelines Working Group du W3C a publiée sous la forme d’une Group Note le 23 juillet 2026, comporte cinq étapes :

1. Définir le périmètre de l’évaluation.
2. Explorer le produit numérique évalué.
3. Choisir un échantillon représentatif.
4. Évaluer l’échantillon choisi.
5. Rendre compte des constats de l’évaluation.

À propos des outils, WCAG-EM 2.0 indique : « Bien que la plupart des vérifications d’accessibilité ne soient pas entièrement automatisables, les outils d’évaluation peuvent aider considérablement les évaluateurs pendant le processus d’évaluation et contribuer à une évaluation plus efficace. » Son exemple : « certains outils d’évaluation de l’accessibilité peuvent scanner un produit numérique entier pour aider à repérer des échantillons pertinents en vue d’une évaluation manuelle ».

WCAG-EM 2.0 distingue aussi les grandes enquêtes de l’évaluation d’un seul produit. Les enquêtes portant sur de nombreux produits sont « généralement menées en recourant surtout à des outils d’évaluation automatisés », et ces évaluations « n’offrent généralement pas la profondeur qualitative nécessaire à l’examen de la conformité de chaque produit, examen pour lequel cette méthodologie est conçue ».

Lors d’un test publié, mené sur un ensemble connu d’obstacles, aucun des outils automatisés testés n’en a trouvé plus de la moitié. Le Government Digital Service (GDS) du gouvernement britannique a délibérément placé 142 obstacles à l’accessibilité sur une page de contenu, puis l’a soumise à 13 outils automatisés. Dans son audit des outils d’accessibilité, mis à jour pour la dernière fois le 13 avril 2018, le meilleur outil a trouvé 40 % des obstacles et le moins bon 13 %. En comptant les obstacles qu’un outil a signalés pour qu’une personne les vérifie, par exemple pour savoir si les textes alternatifs étaient exacts, le meilleur outil a atteint 50 %. Le README du projet le résume ainsi : les outils de vérification automatique sont « utiles pour trouver des problèmes simples et évidents, mais incapables de détecter bon nombre de problèmes d’accessibilité ». Les chiffres proviennent de versions d’outils de 2017 et 2018 et d’une page de test conçue à cet effet, non d’une vraie boutique : ils indiquent une fourchette, et non un taux applicable à une boutique aujourd’hui.

Les outils peuvent donner des chiffres différents pour une même page. Ils ne testent pas tous les mêmes choses, comme le montre l’écart observé dans l’audit du GDS, et ils ne lisent pas tous les WCAG de la même manière. Le guide pour proposer des règles d’axe-core indique que « tous les testeurs n’ont pas la même interprétation des recommandations d’accessibilité », et que toutes ses règles doivent être cohérentes avec l’interprétation de Deque Systems, la société qui développe axe-core.

Les grandes enquêtes automatisées font apparaître la même limite, vue de l’autre côté. L’analyse de WebAIM portant sur les pages d’accueil des 1 000 000 de sites web les mieux classés, avec des données de février 2026, a détecté des échecs aux WCAG 2 sur 95,9 % d’entre elles. WebAIM ajoute sa propre réserve : « Comme seuls les échecs aux WCAG détectables automatiquement ont été pris en compte, cela laisse penser que le taux de conformité complète aux WCAG 2 A/AA était certainement inférieur à 4,1 %. » Les six types d’échec les plus fréquents dans cette analyse sont tous d’un genre qu’une règle automatisée peut détecter : texte à faible contraste, alternatives textuelles manquantes pour les images, étiquettes manquantes sur les champs de formulaire, liens vides, boutons vides et langue du document manquante. Une telle liste montre ce que les outils peuvent voir. Ce n’est pas un classement de tous les obstacles.

Le scanner de Validiscan exécute des règles automatisées, et une personne parcourt une liste de vérifications manuelles. Les critères de succès que testent les règles, et ceux pour lesquels la liste comporte un point, sont publiés critère par critère.

Le scanner exécute 102 règles : 79 règles d’axe-core et 23 contrôles que Validiscan a écrits lui-même, dont beaucoup portent sur ce qu’axe-core ne teste pas, comme les pièges au clavier, l’ordre du focus et le reflow. En outre, 11 règles d’axe-core sont désactivées parce qu’un contrôle propre à Validiscan teste la même chose, de sorte qu’un même élément ne donne jamais deux constats, et 15 ne sont pas exécutées parce qu’axe-core les marque comme expérimentales ou obsolètes, ou parce qu’elles ne testent que le niveau AAA. Le catalogue des règles répertorie chaque règle avec son statut.

Certains contrôles propres à Validiscan interagissent avec la page. L’un « suit la séquence de tabulation et détecte les boucles et les impasses » ; un autre « affiche les pages sur une largeur de 320 pixels CSS (l’équivalent d’un zoom à 400 %) ». Ils mesurent un comportement. Ils ne jugent pas du sens.

Sur les 55 critères de succès des WCAG 2.2 aux niveaux A et AA, 33 sont testés par au moins une règle que le scanner exécute. Les 22 autres ne sont testés par aucune règle que le scanner exécute, et chacun d’eux a un point dans la liste de vérifications manuelles, qui compte 35 points. La liste comporte aussi des points pour certains critères qu’une règle ne teste qu’en partie, comme l’utilisation au clavier, l’ordre du focus et les sous-titres. Pour les autres critères qu’une règle teste, la liste ne comporte aucun point. La matrice des critères indique, pour chaque critère de succès, les règles qui le testent et si la liste de vérifications manuelles comporte un point le concernant.

Pour chaque point de la liste, Validiscan enregistre le résultat (réussi, échoué ou non applicable), avec des notes et, le cas échéant, un fichier de preuve. Les résultats figurent dans la section « Revue manuelle et constats exclus » du Remediation Evidence Package. La section « Périmètre et méthodologie » du dossier de preuves énumère les limites de l’évaluation, dont celles-ci :

• « Les contrôles automatisés ne détectent qu’une partie des obstacles à l’accessibilité. Un critère n’est considéré comme satisfait que si les contrôles automatisés le couvrent entièrement ou si une vérification manuelle a réussi. »
• « Les contenus intégrés dans des cadres d’une autre origine (cross-origin) ou dans un shadow DOM fermé, comme les champs de paiement et certains outils de consentement et widgets, ne sont pas évalués automatiquement. »

Dans l’application de Validiscan, les contrôles automatisés sont considérés comme couvrant entièrement un critère lorsqu’une règle exécutée par le scanner le teste et que la liste de vérifications manuelles ne comporte aucun point pour ce critère. Pour un tel critère, un résultat « Satisfait » dans le dossier de preuves repose sur les seuls contrôles automatisés. Au 6 octobre 2026, parmi ces critères figurent certains que le regroupement ci-dessus laisse à une personne le soin de trancher, comme 1.1.1 Non-text Content et 2.4.4 Link Purpose (In Context).

Aujourd’hui, le scanner ne conserve pas les résultats qu’une règle marque comme « à examiner » : ils n’apparaissent donc pas comme des constats. La page de méthode cite ce point parmi les limites.

Le dossier de preuves fait état, critère par critère, de la conformité aux critères de succès des WCAG 2.1 niveau AA et des WCAG 2.2 niveau AA, telle qu’évaluée sur les pages et aux dates indiquées. Ce dossier constitue la preuve d’une évaluation et de travaux de correction. Il ne s’agit pas d’un certificat, et il ne se prononce pas sur la conformité juridique. La vérification gratuite est entièrement automatisée, sans vérification manuelle : les échecs qu’elle signale ne constituent donc pas un total.