Couverture WCAG

Les WCAG 2.2 comptent 55 critères de succès actifs de niveaux A et AA. AllyProof exécute des règles automatisées qui détectent des conditions d'échec pour 25 d'entre eux. C'est une affirmation sur la détection, non sur la conformité : une analyse qui ne trouve rien a écarté les schémas d'échec couverts par ses règles, et rien de plus. Cette page explique ce que signifie chaque catégorie, et où se situe l'écart.

Ce que mesurent réellement les tests automatisés

Le chiffre cité dans tout le secteur est 57 %, et il est régulièrement mal interprété. Il provient du rapport de couverture de Deque, qui a analysé environ 2 000 audits portant sur plus de 13 000 pages et quelque 300 000 problèmes recensés. Dans ce corpus, les tests automatisés ont identifié 57,38 % du total des problèmes d'accessibilité recensés.

Il s'agit d'une part du volume de problèmes, non d'une part des critères de succès. Le même rapport précise que des problèmes automatisés n'existaient que pour 16 des 50 critères de succès WCAG 2.1 de niveaux A et AA qu'il a analysés. Les règles automatisées se concentrent sur les défaillances les plus fréquentes - alternatives textuelles manquantes, contraste, étiquettes absentes -, ce qui explique qu'elles détectent la majorité des problèmes tout en ne touchant qu'une minorité de critères.

L'énoncé honnête est donc :

Les tests d'accessibilité automatisés identifient de nombreux schémas d'échec WCAG courants, mais ne peuvent pas établir la conformité aux WCAG. Dans le corpus d'audits de Deque, les tests automatisés ont identifié 57,38 % des problèmes d'accessibilité recensés - une part du volume de problèmes, et non la part des critères de succès WCAG évaluables intégralement de façon automatisée. La couverture réelle varie d'un site à l'autre.

AllyProof n'a pas publié son propre test de référence : il ne cite donc aucun pourcentage de détection qui lui serait propre. Ce qu'il indique en revanche, critère par critère dans les tableaux ci-dessous, c'est quels critères ses règles couvrent et lesquels elles ne couvrent pas.

Ce que signifie un résultat sans anomalie

Un résultat automatisé sans anomalie signifie que l'analyseur n'a pas détecté les schémas d'échec couverts par ses règles. Il n'établit pas la conformité au critère de succès dans son ensemble.

C'est pourquoi AllyProof ne transforme jamais une absence de résultat en affirmation de conformité. Dans un projet d'Accessibility Conformance Report, un critère sans échec détecté reçoit un statut d'élément recueilli (« Automated checks completed - no failure detected ») et un niveau de conformité vide, à remplir par un évaluateur humain - et non la mention « Supports ».

WCAG 2.2 - nouveautés d'octobre 2023

Les WCAG 2.2 (recommandation du W3C d'octobre 2023 ; ISO/IEC 40500:2025) ont ajouté neuf critères de succès aux WCAG 2.1 et en ont retiré un. Les résultats rattachés à l'un des neuf nouveaux critères portent une pastille New in 2.2 sur la fiche du problème : les clients qui se situent par rapport à la version 2.2 voient ainsi d'un coup d'œil quels problèmes n'auraient pas existé sous la norme antérieure.

2.4.11 Focus non masqué (minimum) - AA
2.4.12 Focus non masqué (amélioré) - AAA
2.4.13 Apparence du focus - AAA
2.5.7 Mouvements de glissement - AA
2.5.8 Taille de la cible (minimum) - AA
3.2.6 Aide cohérente - A
3.3.7 Saisie redondante - A
3.3.8 Authentification accessible (minimum) - AA
3.3.9 Authentification accessible (améliorée) - AAA

Le critère 4.1.1 Analyse syntaxique a disparu

Le critère 4.1.1 Analyse syntaxique est obsolète et a été supprimé dans les WCAG 2.2. Ce n'est pas une exigence active des WCAG 2.2, et AllyProof ne le présente pas comme telle.

L'analyseur continue d'exécuter les règles sur les identifiants dupliqués et le balisage mal formé, car elles restent des indicateurs de qualité utiles et peuvent révéler des échecs à d'autres critères. Le W3C indique désormais que le critère 4.1.1 doit être considéré comme toujours satisfait pour HTML et XML, et que les effets d'identifiants dupliqués ou d'un balisage mal formé doivent être rapportés sous le critère qu'ils affectent réellement. Les éditions fondées sur une norme antérieure conservent une ligne 4.1.1 héritée, clairement signalée, par souci d'exhaustivité structurelle, mais AllyProof ne lui attribue pas automatiquement de niveau de conformité.

Comment AllyProof classe les critères

Les catégories décrivent les éléments que l'automatisation peut produire, et non le degré d'« automatisabilité » d'un critère. Rien ici n'implique qu'un résultat sans anomalie prouve la conformité.

Catégorie	Signification
Détection automatisée des échecs disponible	Des règles détectent de façon fiable les conditions d'échec courantes de ce critère. Un échec détecté est un élément solide ; un résultat sans anomalie n'établit pas la conformité.
Partiellement testable par automatisation	Des règles détectent certaines conditions d'échec. Des pans importants du critère échappent à ce qu'un analyseur peut observer.
Évaluation manuelle indispensable	Aucune règle automatisée ne couvre ce critère. Il exige une personne.

Catalogue de règles : difficulté et vérification

Chaque fiche de problème s'appuie sur un catalogue de règles statique qui, lorsque nous avons rencontré la règle assez souvent pour l'étalonner, indique :

Le niveau de difficulté : facile (balisage mécanique, moins de 5 minutes), moyen (code et décision de conception mineure, 5 à 20 minutes), difficile (revue de conception, réécriture de contenu ou changement d'architecture, plus de 20 minutes).
L'estimation de temps : durée médiane approximative, en minutes, pour corriger une occurrence, visible dans la ligne Effort de la bande de métadonnées.
La recette de vérification avec une technologie d'assistance : l'outil (NVDA, VoiceOver, JAWS, clavier, outils de développement) et des étapes numérotées pour confirmer la correction. Elle s'affiche en section « Verify with NVDA » sous la suggestion de correction par IA, afin qu'une équipe qualité non spécialiste de l'accessibilité puisse mener la vérification manuelle.

La liste des problèmes comporte également une pastille Quick wins qui filtre les problèmes ouverts du site sur le niveau facile - utile pour répondre à « que peut traiter une personne junior cet après-midi ? » sans écrire de requête.

Couverture par principe WCAG

Les décomptes proviennent du catalogue de critères d'AllyProof, qui contient les 55 critères de succès actifs des WCAG 2.2 de niveaux A et AA.

Principe	Critères A/AA actifs	Détection automatisée des échecs	Partiellement testable	Évaluation manuelle indispensable
1. Perceptible	20	4	8	8
2. Utilisable	20	5	3	12
3. Compréhensible	13	2	1	10
4. Robuste	2	1	1	0
Total	55	12	13	30

Critères avec détection automatisée des échecs

Des règles détectent de façon fiable les conditions d'échec courantes de ces critères. Lisez chaque ligne comme ce à quoi ressemble un échec du point de vue de l'analyseur, et non comme une liste de contrôle dont la réussite satisferait le critère.

1.3.1 Information et relations : détecte les défaillances de structure de titres, d'étiquetage de formulaire et de balisage de tableau. Ne peut pas confirmer que chaque relation visuelle est représentée par programme.
1.3.4 Orientation : détecte les verrouillages d'orientation en CSS et dans les métadonnées de la fenêtre d'affichage.
1.4.3 Contraste (minimum) : calcule les rapports de contraste entre premier plan et arrière-plan lorsque les deux sont déterminables.
1.4.12 Espacement du texte : détecte les déclarations qui empêchent de modifier l'espacement du texte.
2.4.1 Contourner des blocs : détecte l'absence de lien d'évitement ou de structure de repères.
2.4.2 Titre de page : détecte un <title> absent ou vide. Ne peut pas juger si le titre décrit la page.
2.4.4 Fonction du lien (selon le contexte) : détecte les liens vides et les intitulés non descriptifs connus. Ne peut pas juger si la fonction est claire d'après le contexte.
2.5.3 Étiquette dans le nom : détecte les étiquettes visibles absentes du nom accessible.
2.5.8 Taille de la cible (minimum) : mesure les dimensions rendues des cibles au regard du minimum de 24 × 24 pixels CSS.
3.1.1 Langue de la page : détecte un attribut lang absent ou invalide sur <html>.
3.1.2 Langue d'un passage : détecte les valeurs lang invalides sur les éléments en ligne. Ne peut pas détecter les passages non signalés rédigés dans une autre langue.
4.1.2 Nom, rôle et valeur : valide les rôles, états et propriétés ARIA, et détecte les commandes dépourvues de nom accessible. Ne peut pas confirmer que le nom, le rôle et la valeur sont corrects dans chaque état de l'application.

Partiellement testables par automatisation

Des règles détectent certaines défaillances et ne voient pas les autres. Un résultat sans anomalie y constitue un élément plus faible encore.

1.1.1 Contenu non textuel : détecte un alt absent ou vide. Ne peut pas juger si l'alternative textuelle est appropriée.
1.3.2 Ordre séquentiel logique : détecte certains schémas de réordonnancement en CSS. Ne peut pas apprécier si l'ordre de lecture est logique.
1.3.5 Identifier la finalité de la saisie : détecte l'absence d'autocomplete sur les champs probables. Ne peut pas vérifier que le jeton retenu est le bon.
1.4.1 Utilisation de la couleur : détecte certaines distinctions de liens par la seule couleur. Ne peut pas relever tous les cas d'information portée par la couleur.
1.4.2 Contrôle du son : détecte les médias en lecture automatique. Ne peut pas apprécier si une commande est repérable.
1.4.4 Redimensionnement du texte : détecte les tailles de police fixes. Ne peut pas vérifier la mise en page à 200 % de zoom.
1.4.10 Redistribution : détecte un dépassement horizontal à la largeur de redistribution. Ne peut pas juger d'une perte de contenu.
1.4.11 Contraste du contenu non textuel : mesure le contraste des limites d'interface identifiables. Ne peut pas évaluer chaque objet graphique.
2.2.2 Mettre en pause, arrêter, masquer : détecte les contenus animés et se mettant à jour automatiquement. Ne peut pas confirmer qu'un mécanisme de pause fonctionne.
2.4.3 Parcours du focus : détecte les tabindex positifs et autres pratiques à proscrire. Ne peut pas apprécier si l'ordre préserve la signification.
2.4.6 En-têtes et étiquettes : détecte les titres et étiquettes vides. Ne peut pas apprécier leur caractère descriptif.
3.3.2 Étiquettes ou instructions : détecte les étiquettes absentes. Ne peut pas apprécier si les instructions sont suffisantes.
4.1.3 Messages d'état : détecte le balisage des régions live. Ne peut pas confirmer que les changements d'état sont effectivement annoncés.

Évaluation manuelle indispensable

Trente des 55 critères n'ont aucune règle automatisée. Ils exigent un jugement humain, des tests avec une technologie d'assistance, ou une évaluation du sens. Par exemple :

1.2.1 à 1.2.5 Médias temporels : exigent une évaluation humaine des sous-titres, de l'audio-description et des transcriptions.
1.3.3 Caractéristiques sensorielles : instructions reposant sur la forme, la couleur, la taille ou l'emplacement.
2.1.1 Clavier et 2.1.2 Pas de piège au clavier : exigent d'utiliser réellement l'interface sans souris.
2.2.1 Réglage du délai : exige de solliciter les expirations de session et les interactions minutées.
2.4.5 Accès multiples : exige d'apprécier les alternatives de navigation à l'échelle du site.
2.4.7 Visibilité du focus : exige de juger la visibilité de l'indicateur dans des états réels.
3.2.3 Navigation cohérente : exige une comparaison entre pages.
3.3.3 Suggestion après une erreur et 3.3.4 Prévention des erreurs : exigent de solliciter la validation des formulaires et les étapes de confirmation.

La page Vérification manuelle avec une technologie d'assistance propose des recettes pas à pas pour vérifier des corrections précises à la main.

Pourquoi pas 100 %

De nombreux critères WCAG portent sur l'intention et le sens, que des outils automatisés ne peuvent fondamentalement pas apprécier :

Cette alternative textuelle est-elle exacte ? (Un outil peut vérifier qu'elle existe, non qu'elle est juste.)
Ces instructions sont-elles claires ? (Cela suppose une compréhension humaine.)
L'ordre de lecture a-t-il du sens ? (Cela suppose de comprendre le contenu.)
Les sous-titres sont-ils synchronisés et exacts ? (Cela suppose de regarder la vidéo.)
Peut-on accomplir une tâche au seul clavier ? (Cela suppose un test interactif.)

C'est une limite inhérente à tout outil d'accessibilité automatisé, et non une particularité d'AllyProof. Ce à quoi AllyProof s'engage, c'est à dire explicitement de quel côté de la ligne se situe chaque critère, afin qu'une analyse sans anomalie ne soit jamais prise pour un résultat de conformité.