Les outils automatiques d’accessibilité : utiles, mais loin d’être suffisants

I. Un enjeu renforcé par le cadre légal

Depuis l’entrée en vigueur de la loi luxembourgeoise du 28 mai 2019 sur l’accessibilité des sites internet et applications mobiles du secteur public, la conformité n’est plus un simple objectif : c’est une obligation.
Dans ce contexte, rédacteurs, développeurs et chefs de projet se posent la même question :
Comment vérifier rapidement qu’une page web respecte les critères d’accessibilité, sans solliciter systématiquement un expert pour un audit manuel long et coûteux ?

Les formations proposées aux agents publics par le gouvernement luxembourgeois constituent une première étape essentielle. Mais pour garantir une accessibilité durable, il faut aller plus loin et s’appuyer sur un écosystème d’outils capable d’accompagner les équipes au quotidien.

II. Trois grandes catégories d’outils automatiques

Les outils automatiques ont vu le jour pour simplifier les audits d’accessibilité. Ces solutions analysent le code des pages web à la recherche de défauts, aidant ainsi à détecter les obstacles potentiels pour les personnes en situation de handicap.

Le marché propose aujourd’hui plusieurs types de solutions permettant d’analyser automatiquement une page web :

Les extensions de navigateur : Ces outils comme Axe, WAVE ou Google Lighthouse s’intègrent directement dans le navigateur. Ils offrent une analyse de la page consulté avec une présentation claire des erreurs détectées. Leur simplicité en fait souvent la porte d’entrée idéale.
Les services en ligne : Des plateformes comme AccessibilityChecker, accessiBe ou UserWay proposent une évaluation (souvent payante) à partir d’une URL sans installation. Elles sont particulièrement utiles pour analyser rapidement un grand nombre de pages.
Les scripts automatisés : Basés sur des solutions comme Cypress ou Selenium,, et fréquemment couplés à Axe Core, ces scripts permettent d’automatiser des tests sur un ensemble de pages et de générer des rapports synthétiques. Ils sont adaptés aux équipes techniques souhaitant intégrer l’accessibilité dans leur pipeline de développement.

Ces outils ont un point commun : ils offrent une analyse rapide, reproductible et indépendante d’une intervention humaine. Mais leur efficacité reste limitée, ils permettent un premier niveau de vérification.

III. Les limites de l’analyse automatisée

Les outils automatiques jouent un rôle important, mais ils ne peuvent couvrir qu’une partie du périmètre d’accessibilité. Plusieurs limites majeures persistent :

Des référentiels incomplets ou inadaptés : Beaucoup d’outils, comme Axe Core, se basent uniquement sur les WCAG (référentiel international), sans tenir compte du RGAA ou du RAWeb, plus spécifiques au contexte luxembourgeois. Cela peut conduire à une évaluation partielle ou inadéquate.
Des tests essentiellement techniques : Les outils automatisés repèrent très bien les erreurs de code (ex : absence d’attribut alt sur une image), cependant, ils ne peuvent pas évaluer la pertinence ou le contexte de celui-ci : Un texte alternatif peut être présent, mais incorrect, et seul un humain peut le juger. Même si l’IA progresse rapidement, elle reste incapable d’évaluer la pertinence d’un texte alternatif ou la logique d’une interface. Ces décisions nécessitent encore un jugement humain.
Un champ de couverture limité : D’après plusieurs études, en moyenne, seulement 20 à 30% des critères d’accessibilité peuvent être testés automatiquement (par exemple avec des scripts javascript). Cela signifie que plus des deux tiers des vérifications doivent encore être faites manuellement.
Une absence de hiérarchisation des erreurs : Ces outils ne prennent pas en compte la criticité des défauts. Une erreur dans le menu principal n’a pas le même impact qu’un défaut dans une page secondaire peu utilisée. Seul un regard manuel peut hiérarchiser les corrections nécessaires.
Des outils pensés pour des experts : La plupart de ces outils s’adressent à des profils techniques ou des spécialistes de l’accessibilité (jargon technique, vocabulaire métier, etc.), limitant leur adoption par des rédacteurs ou des chefs de projet peu familiers avec le sujet.

IV. Quelle solution pour demain ?

Si l’audit manuel par un expert reste aujourd’hui la méthode la plus fiable pour une évaluation complète et conforme, la meilleure approche est encore la prévention. En formant les designers, développeurs, contributeurs et chefs de projet à l’accessibilité dès la phase de conception, on diminue considérablement les risques d’inaccessibilité.

Pour améliorer les outils actuels, il serait pertinent de mettre en place un ecosystème d’outil. La première pièce de cet écosystème serait de développer une extension de navigateur plus adaptée, intégrant :

Une base fondée sur le RAWeb (ou à minimum sur le RGAA),
Une interface compréhensible aux non-experts,
Une compatibilité avec des outils comme Cypress/Selenium, pour tester automatiquement un grand nombre de pages,
Des recommandations concrètes pour améliorer la qualité et la conformité des contenus.

La création sur-mesure de cet outil de vérification automatique de l’accessibilité est un bon point de départ. En complément, il faudrait mettre en place d'autres pièces pour completer le puzzle de l'écosystème :

Un Design System contenant les divers points d'accessibilité à vérifier pour chaque composant
Un système de suivi de l'accessibilité avec Cypress/Selenium pour éviter tous risques de régression
Un CMS dont les composants sont accessibles et qui donnerait des conseils si l'utilisateur saisi du contenu avec des erreurs d'accessibilité
Un processus côté design pour s'assurer que les maquettes Figma/XD respectent le niveau requis de contraste

Utiliser des composants définis dans un design system et implémentés dans un CMS C'est le moyen le plus simple pour avoir une structure conforme. De plus cela permet l'écriture de tests ciblés et pertinent. Avec ce genre de pratique, on peut franchir la barre des 30% de couverture des critères par les tests automatiques.

V. Conclusion

Le principal avantage de l'outil de vérification automatique de l’accessibilité c'est de pouvoir analyser rapidement une page et de remonter les erreurs usuelles.

Un écosystème complet permettrait d’anticiper, détecter et corriger une grande partie des problèmes d’accessibilité. Mais il ne remplacera jamais un audit complet réalisé par un expert.

Cet éco-système ne pourra pas servir pour rédiger et maintenir la déclaration d'accessibilité, mais pourra permettre d'éviter des régressions sur des problèmes déjà corrigé.

Si vous connaissez ou développez une solution qui répond aux exigences évoquées, n’hésitez pas à le partager. Car c’est en mutualisant les efforts que l’on pourra réellement avancer vers un web plus inclusif.