Tests de conformité à l'accessibilité (ACT) expliqués
Les tests de conformité d'accessibilité vérifient un produit au regard des WCAG. Ce qu'ils couvrent, automatique et manuel, et ce qu'exige un ACR.
Qu'est-ce qu'un test de conformité à l'accessibilité ?
Un test de conformité à l'accessibilité consiste à vérifier un site web, une application ou un document au regard d'une norme d'accessibilité, le plus souvent les Web Content Accessibility Guidelines (WCAG), et à noter pour chaque exigence si elle est satisfaite, non satisfaite ou non applicable. Le résultat est une liste de constats pour un niveau de conformité annoncé (A, AA ou AAA), que l'équipe peut corriger et qu'un acheteur peut lire. Le même sigle désigne aussi un format du W3C, l'ACT Rules Format, qui décrit comment s'écrivent les règles de test individuelles.
Deux sens de « ACT »
- L'activité. Évaluer un produit au regard des WCAG (WCAG 2.2 est la version recommandée par le W3C) ou d'une norme qui s'y appuie, avec des outils et une revue humaine.
- L'ACT Rules Format du W3C. Une Recommandation du W3C (version 1.1) qui définit une structure commune pour les règles de test : à quoi la règle s'applique, ce qu'elle attend, et l'un de cinq résultats : passed, failed, inapplicable, cantTell ou untested. Les règles peuvent être automatiques, manuelles ou mixtes, ce qui permet à différents outils et testeurs d'interpréter une exigence de la même façon.
Comment se déroule un test de conformité
- Définir le périmètre et la cible. Choisissez le produit, les pages ou parcours concernés et le niveau, généralement WCAG 2.2 AA.
- Choisir un échantillon. Quand vérifier chaque page n'est pas possible, la méthode WCAG-EM du W3C recommande un échantillon représentatif de vues, choisies de façon structurée et aléatoire.
- Lancer les vérifications automatiques. Des outils comme axe ou Lighthouse repèrent les problèmes détectables dans le code, par exemple des étiquettes de formulaire manquantes ou un contraste trop faible.
- Faire les vérifications manuelles. Des personnes testent l'ordre de navigation au clavier, la visibilité du focus et l'ordre de lecture, et utilisent un lecteur d'écran. Voir les tests manuels d'accessibilité.
- Rendre compte. Notez réussite ou échec par critère de succès avec les étapes suivies, puis retestez après correction.
Exemple
Une équipe vise WCAG 2.2 AA pour un parcours de paiement. Une analyse automatique signale un texte dont le rapport de contraste est inférieur aux 4,5:1 exigés par WCAG pour le texte normal. Une passe manuelle découvre ensuite que le champ du code promo est inaccessible au clavier, ce qu'aucun outil n'avait signalé. Les deux entrent dans le rapport comme échecs sur des critères de succès nommés, sont corrigés puis retestés.
L'automatique ne couvre qu'une partie des WCAG
Le score d'accessibilité de Lighthouse est une moyenne pondérée d'audits automatiques réussi ou échoué, et sa propre documentation présente les vérifications manuelles, comme l'ordre logique de tabulation et les pièges à focus, à part du score. Un score parfait ne signifie donc pas qu'une page est conforme aux WCAG. À lire aussi : tests d'accessibilité automatisés.
Tests de conformité et ACR
Un Accessibility Conformance Report (ACR) est le modèle VPAT rempli ; il doit reposer sur une évaluation manuelle et pas seulement sur le passage d'un outil automatique. L'Information Technology Industry Council (ITI), qui publie le VPAT, ne relit ni n'approuve les VPAT et il n'existe pas de certification VPAT : l'exactitude du rapport relève donc du fournisseur.
Erreurs fréquentes
- Traiter un score Lighthouse de 100 comme une déclaration de conformité.
- Ne tester que la page d'accueil au lieu d'un échantillon qui inclut formulaires, tableaux, boîtes de dialogue et états d'erreur.
- Ignorer les technologies d'assistance : tester seulement à la souris cache la plupart des échecs clavier et lecteur d'écran.
- Ne pas indiquer la norme, la version et le niveau, si bien que personne ne sait ce que « conforme » veut dire.
La place de LoadFocus
LoadFocus ne produit pas de rapports de conformité d'accessibilité et ne certifie pas la conformité. La surveillance de la vitesse des pages lance des audits Lighthouse planifiés qui incluent un score d'accessibilité, utile comme alerte automatique entre deux évaluations complètes. Pour voir comment tests de performance et d'accessibilité s'articulent, lisez pourquoi les tests de performance doivent inclure l'accessibilité.
Questions fréquentes
Les outils automatiques peuvent-ils prouver la conformité aux WCAG ?
Non. Les outils automatiques ne détectent que les problèmes visibles dans le code, et Lighthouse présente lui-même les vérifications manuelles à part de son score. La conformité exige aussi une évaluation manuelle.
Quelle différence entre ACT et WCAG-EM ?
L'ACT Rules Format définit comment s'écrivent les règles de test individuelles pour que outils et testeurs obtiennent des résultats cohérents. WCAG-EM est une méthode du W3C pour évaluer un site entier : périmètre, échantillon, évaluation et rapport.
Faut-il des tests de conformité pour obtenir un ACR ?
Oui. Un ACR indique comment un produit satisfait chaque critère et doit reposer sur une évaluation de ce produit. L'ITI ne relit pas les ACR, l'exactitude relève donc du fournisseur.
Quelle version et quel niveau des WCAG tester ?
Le W3C recommande la version la plus récente, WCAG 2.2. Le niveau AA est la cible habituelle pour les marchés publics et les exigences légales, mais vérifiez la norme que cite votre client ou votre régulateur.
Termes associés
- Définition de l'accessibilité numérique
- Technologie d'assistance (AT) : définition, types, exemples web
- Tests manuels d'accessibilité
- POUR en accessibilité
- Qu'est-ce qu'un lecteur d'écran ? Définition et tests
- Liste de contrôle d'accessibilité logicielle (WCAG 2.2)
- Qu'est-ce qu'un VPAT (Voluntary Product Accessibility Template) ?
- Web Accessibility Initiative (WAI) : définition et normes
Outils LoadFocus connexes
Mettez ce concept en pratique avec LoadFocus, la plateforme même qui propulse tout ce que vous venez de lire.