Tests et outils

Tests d'accessibilité automatisés et manuels

Aucun analyseur d'accessibilité automatisé - y compris celui d'AllyProof - ne peut évaluer 100 % des WCAG à lui seul, et tout outil qui l'affirme doit être considéré avec scepticisme.

Avant le détail, une distinction qui explique l'essentiel de la confusion dans ce domaine. On compte deux choses différentes :

• Le volume de problèmes - la part des problèmes d'accessibilité réellement présents sur un site qu'un analyseur détecte. Le rapport de couverture de Deque, établi sur environ 2 000 audits, a mesuré que les tests automatisés identifiaient 57,38 % des problèmes recensés. C'est de là que vient le chiffre de « 57 % » souvent cité.
• Les critères - la part des critères de succès WCAG sur lesquels un analyseur peut dire quelque chose. Le même rapport n'a relevé de problèmes automatisés que pour 16 des 50 critères WCAG 2.1 A/AA présents dans son corpus.

Les règles automatisées obtiennent un bien meilleur score en volume qu'en critères, parce que les défaillances qu'elles vérifient sont aussi les plus fréquentes. Aucun de ces chiffres ne signifie qu'une analyse sans erreur établit la conformité : les règles automatisées détectent des conditions d'échec, elles ne confirment jamais qu'un critère est satisfait.

Au niveau des critères, le tableau se divise en trois. Les décomptes ci-dessous correspondent au classement propre à AllyProof des 55 critères de succès actifs des WCAG 2.2 de niveaux A et AA.

Détection automatisée des échecs disponible (12 sur 55, environ 22 %)

Ces critères présentent des conditions observables par une règle, comme un attribut manquant ou un calcul de contraste. Examinez les éléments enregistrés et leur contexte au moment de la revue. Une règle qui n'a signalé aucun échec n'établit pas que le critère entier est satisfait. Voir axe-core expliqué.

Exemples : Contraste insuffisant (1.4.3), Langue de la page absente (3.1.1), Titre de page absent (2.4.2), Attributs ARIA invalides (4.1.2).

Partiellement testables par automatisation (13 sur 55, environ 24 %)

Un analyseur peut détecter un motif qui est souvent - mais pas toujours - un problème réel, et qui demande confirmation humaine. La présence d'un attribut alt se vérifie mécaniquement ; savoir si l'alternative est une bonne description suppose qu'une personne la lise et en juge - raison pour laquelle le critère Contenu non textuel (1.1.1) figure ici et non dans la catégorie précédente. L'existence d'une structure de titres se vérifie ; savoir si les titres sont explicites (critère En-têtes et étiquettes) relève du jugement humain.

Évaluation manuelle indispensable (30 sur 55, environ 55 %)

Plus de la moitié des critères actifs A/AA exigent réellement une personne - aucune approche automatisée actuelle ne peut les évaluer :

• Si l'audiodescription restitue fidèlement le contenu visuel d'une vidéo
• Si l'ordre de lecture d'une page est réellement logique (et pas seulement cohérent sur le plan structurel)
• Si l'ordre de focus au clavier correspond au déroulement logique voulu
• Si les messages d'erreur sont réellement utiles, et pas seulement techniquement présents

Pourquoi la transparence compte plus que le pourcentage

Le pourcentage exact importe bien moins que la transparence sur la catégorie dont relève chaque critère pour une analyse donnée, et sur ce qu'un résultat sans erreur établit réellement dans chaque catégorie. Un rapport qui sépare clairement « non-conformités confirmées », « revue manuelle nécessaire » et « aucune règle automatisée - audit manuel requis » est plus fiable et plus utile qu'un rapport qui surévalue sa couverture ou agrège tout dans un « score » unique sans méthodologie. C'est aussi ce qui a fondé la décision de la FTC d'avril 2025 à l'encontre d'accessiBe : le problème tenait à des affirmations que les éléments ne soutenaient pas, non au recours à l'automatisation.

Ce que cela implique en pratique

Traitez une analyse automatisée comme un solide premier passage, qui repère de façon fiable les problèmes les plus souvent cités et les plus exposés juridiquement (voir Tendances des contentieux d'accessibilité web : les non-conformités les plus fréquentes sont presque toutes bien détectées par l'automatisation) - mais pas comme un substitut à un audit manuel complet si la conformité WCAG est l'objectif, en particulier pour tout ce qui est destiné au public et comporte des enjeux juridiques ou de réputation réels.

Questions fréquentes

Quelle part des WCAG les outils automatisés peuvent-ils tester ?

Deux chiffres circulent et ne mesurent pas la même chose. Par critères : les règles automatisées détectent des conditions d'échec courantes pour environ 22 % des 55 critères actifs des WCAG 2.2 A/AA, en couvrent partiellement 24 % de plus, et ne touchent pas les 55 % restants. Par volume : Deque a mesuré que les tests automatisés identifiaient 57,38 % des problèmes recensés dans son corpus d'audits. Aucun de ces chiffres ne signifie qu'une analyse sans erreur établit la conformité.

Un analyseur automatisé peut-il rendre un site conforme aux WCAG ?

Non. Aucun outil automatisé ne peut évaluer l'ensemble des WCAG, et tout outil qui l'affirme doit être considéré avec scepticisme. Plus de la moitié des critères n'ont aucune règle automatisée, et même là où des règles existent, elles détectent des échecs plutôt que de confirmer une réussite.

À quoi servent les tests d'accessibilité automatisés ?

À un premier passage fiable, qui repère les problèmes les plus fréquents et les plus exposés juridiquement - alternatives textuelles manquantes, contraste insuffisant, étiquettes absentes - avant qu'un audit manuel ne couvre le reste.