Qu'est-ce que les tests d'accessibilité automatisés ?

Qu'est-ce que les tests d'accessibilité automatisés ?

Les tests d'accessibilité automatisés utilisent un logiciel, comme un moteur de règles, un audit de navigateur ou un linter, pour analyser une page ou un composant à la recherche d'échecs d'accessibilité qu'un programme peut détecter : texte alternatif absent, champ sans étiquette, contraste de couleur insuffisant, ARIA invalide. Rapides et reproductibles, ils sont idéaux pour attraper les régressions, mais ne couvrent qu'une partie des WCAG. Le reste doit être jugé par une personne.

Comment ça fonctionne

Un outil charge le DOM rendu, lui applique un ensemble de règles et signale chaque élément en échec, en général avec la règle, le critère WCAG et une suggestion de correction. Les options courantes :

• Moteurs de règles comme axe-core, exécutés dans des tests unitaires, de composants ou de bout en bout, afin qu'une règle enfreinte fasse échouer le build.
• Audits de navigateur comme Lighthouse, qui transforme un ensemble d'audits automatiques en un score d'accessibilité de 0 à 100. Lighthouse pondère ces audits avec les évaluations d'impact d'axe, et chaque audit est réussi ou échoué : un bouton sans nom fait échouer tout l'audit sur les noms de boutons.
• Linters dans l'éditeur ou la CI, qui signalent les problèmes de balisage avant la mise en ligne.

Ce qu'ils ne peuvent pas faire

Selon le guide d'évaluation du W3C, aucun outil seul ne peut déterminer si un site respecte les normes d'accessibilité, et une évaluation humaine compétente est nécessaire. Le README d'axe-core indique lui-même qu'il trouve en moyenne 57 % des problèmes WCAG automatiquement et signale les éléments incertains comme « incomplete » pour une revue manuelle. C'est le chiffre de l'éditeur pour ses propres règles : prenez-le comme un ordre de grandeur, pas comme une garantie. Un outil voit qu'une image a un texte alternatif, pas s'il est pertinent. Il ne sait pas si l'ordre de tabulation est cohérent, si un message d'erreur est compréhensible ni ce que vit réellement une personne qui utilise un lecteur d'écran. Lighthouse lui-même liste des vérifications manuelles, comme l'ordre logique de tabulation et la gestion du focus, qui n'entrent pas dans le score.

Un exemple dans une chaîne CI

Une équipe ajoute axe-core à ses tests de bout en bout des pages d'inscription et de paiement. À chaque pull request, le build échoue si une nouvelle infraction apparaît, par exemple un champ sans étiquette. Avant chaque version, une personne parcourt ces pages à la touche Tab et avec un lecteur d'écran. L'exécution automatique attrape les régressions à chaque commit, et le passage manuel trouve ce que les règles ne voient pas, voir les tests manuels d'accessibilité.

Erreurs fréquentes

• Considérer un score Lighthouse de 100 comme la preuve de l'accessibilité ou de la conformité WCAG.
• Ne scanner que la page d'accueil, pas les états connectés, les boîtes de dialogue, les erreurs et le paiement.
• Ne jamais regarder les résultats « incomplete » ou « à vérifier ».
• Corriger l'alerte de l'outil sans vérifier l'expérience réelle, par exemple en mettant un texte alternatif absurde juste pour satisfaire la règle.
• Les lancer une fois avant la mise en production au lieu de le faire à chaque changement.

Leur place dans les tests et la surveillance

Les tests automatisés sont une couche parmi d'autres. Ils s'ajoutent aux vérifications au clavier, aux tests avec lecteur d'écran et aux méthodes formelles décrites dans accessibility conformance testing. Même un audit approfondi n'est pas un rapport de conformité : ce que représente ce document est expliqué dans accessibility conformance report. La surveillance de la vitesse des pages de LoadFocus lance des audits Lighthouse planifiés et enregistre la catégorie Accessibilité avec Performances, SEO et Bonnes pratiques, pour que vous suiviez le score dans le temps. C'est un suivi des régressions, pas un audit d'accessibilité ni un rapport de conformité. Pour aller plus loin, voir tests de performance et métriques d'accessibilité et le panorama des outils de test d'accessibilité.

Questions fréquentes : tests d'accessibilité automatisés

Quel pourcentage des problèmes d'accessibilité les outils automatiques trouvent-ils ?

Cela dépend de l'outil et du site. Le README d'axe-core avance 57 % en moyenne des problèmes WCAG, estimation de Deque pour ses propres règles. Dans tous les cas, une part exige des tests manuels.

Lighthouse est-il un audit d'accessibilité ?

Non. Il exécute un ensemble d'audits automatiques et donne un score pondéré. Un 100 signifie que ces audits sont passés, pas que la page est accessible.

Les tests automatisés peuvent-ils rendre mon site conforme aux WCAG ?

Non. Ils aident à trouver et à prévenir beaucoup d'échecs, mais la conformité exige une évaluation manuelle des critères de succès.

Quand lancer les tests d'accessibilité automatisés ?

À chaque pull request ou build pour les pages et composants clés, et de façon planifiée pour les pages en ligne, afin de repérer tôt les régressions.

Que dois-je tester à la main ?

L'utilisation au clavier et l'ordre du focus, le comportement avec un lecteur d'écran, le zoom et le reflow, les textes alternatifs pertinents, les messages d'erreur et chaque widget personnalisé.