Pourquoi l'accessibilité web ne peut toujours pas être automatisée en 2026

En 2026, les outils d'audit automatisé n'ont jamais été aussi nombreux ni aussi sophistiqués. Lighthouse, axe DevTools, WAVE, Pa11y… Et pourtant : selon une étude WebAIM réalisée sur un million de sites web, 94,8 % des pages d'accueil présentent encore des violations WCAG. Ce paradoxe n'est pas une simple anomalie statistique. Il révèle une limite structurelle que même les systèmes d'intelligence artificielle les plus avancés ne parviennent pas à franchir.

Comprendre pourquoi, concrètement, techniquement, humainement, est aujourd'hui indispensable pour toute organisation soumise au RGAA ou à l'European Accessibility Act (EAA), en vigueur depuis juin 2025.

Ce que les outils automatisés peuvent vraiment détecter

Soyons clairs : les outils d'audit automatisé ont une utilité réelle. Ils permettent de détecter rapidement les erreurs structurelles les plus fréquentes, notamment :

• L'absence d'attribut alt sur une image : l'outil vérifie si l'attribut est présent dans le code HTML.
• Les problèmes de contraste de couleurs : en comparant les valeurs hexadécimales du texte et de son arrière-plan par rapport aux seuils WCAG.
• La hiérarchie des titres (h1 → h2 → h3) : en analysant la structure sémantique du document.
• L'absence de label sur un champ de formulaire : en vérifiant l'association programmatique entre champ et étiquette.
• Certaines erreurs ARIA : utilisation incorrecte de rôles ou d'attributs d'accessibilité dans le code.

Ces vérifications sont précieuses, surtout intégrées directement dans les pipelines de développement (CI/CD avec axe-core ou Lighthouse CI), ce qui permet de bloquer automatiquement le déploiement d'une régression critique.

Mais voilà la réalité chiffrée : ces outils ne couvrent que 30% des critères du RGAA. Les 70 % restants nécessitent une analyse humaine. Et c'est précisément là que le sujet devient complexe.

Pourquoi 60 à 70 % des problèmes échappent à l'automatisation

La présence ne suffit pas : le cas de l'image décorative vs informative

C'est l'exemple le plus emblématique, et pourtant le moins bien expliqué dans la plupart des ressources disponibles.

Un outil automatisé peut vérifier qu'une image possède un attribut alt. Ce qu'il ne peut pas faire, c'est déterminer si le contenu de cet attribut est pertinent.

Prenons un cas concret : une plateforme de e-commerce affiche une photo de produit (disons, une chaussure) avec l'attribut alt="IMG_4521.jpg". L'outil automatisé ? Il ne détectera aucune erreur : l'attribut existe. Pourtant, pour un utilisateur aveugle, cette description est totalement inutile.

À l'inverse, une image purement décorative (un fond graphique sans valeur informative) doit avoir un alt vide (alt=""). Si un développeur lui a attribué une description longue et redondante, l'outil ne signalera rien, mais l'expérience avec un lecteur d'écran sera dégradée, avec des annonces parasites qui perturbent la compréhension.

La règle est simple à énoncer, mais impossible à automatiser : l'outil ne connaît pas l'intention éditoriale de l'image.

La compréhensibilité du contenu : un critère radicalement humain

Le RGAA impose que le contenu soit compréhensible (thématique 9 sur les 13 du référentiel). Cela couvre notamment :

• La pertinence des intitulés de liens ("cliquez ici" versus "Télécharger le rapport annuel 2024")
• La cohérence de la navigation entre les pages
• La lisibilité du langage pour les personnes ayant des troubles cognitifs

Aucun algorithme ne peut évaluer si un texte est réellement compréhensible pour un utilisateur ayant un niveau de lecture de CM2, si un formulaire d'inscription est logiquement organisé, ou si un message d'erreur explique clairement quoi corriger. Ce sont des jugements qui nécessitent une lecture humaine, contextuelle, empathique.

L'expérience réelle avec un lecteur d'écran ne se simule pas

Un critère RGAA comme la restitution vocale d'une liste de navigation, d'un composant carrousel ou d'une modale dynamique ne peut être validé qu'en le testant avec un véritable lecteur d'écran (NVDA, VoiceOver) sur un vrai navigateur.

L'outil automatisé vérifie la présence des bons attributs ARIA, mais pas si l'annonce vocale produite est cohérente, intelligible ou utile. Un composant peut être techniquement "valide" d'un point de vue ARIA et pourtant créer une expérience catastrophique pour un utilisateur non-voyant.

Le contexte métier : une variable invisible pour tout outil

Un formulaire de simulation d'assurance, une interface de réservation médicale, un espace client bancaire : ces pages ont des logiques d'usage spécifiques, des parcours critiques, des états d'erreur propres à leur domaine. Aucun crawler ne comprend ces flux. Il ne sait pas que le champ "N° de sécurité sociale" doit être accompagné d'une explication de format, ni que le bouton "Valider" déclenche une action irréversible qui mérite un avertissement accessible.

Les solutions IA "tout-en-un" : une promesse non tenue, documentée officiellement

Face aux limites des audits classiques, une nouvelle catégorie de produits a émergé : les outils de surcouche d'accessibilité (ou accessibility overlays), souvent commercialisés comme des solutions IA capables de rendre un site conforme en quelques lignes de code JavaScript.

Ces outils permettent généralement à l'utilisateur d'ajuster le contraste, d'agrandir les polices, ou de déclencher un "mode accessibilité". Ils sont vendus avec des arguments séduisants : rapidité de déploiement, conformité garantie, intelligence artificielle.

Pourtant, la position des institutions les plus sérieuses en la matière est unanime et sans appel :

• La Commission européenne a clairement indiqué que ces outils ne constituent pas une solution appropriée et qu'ils peuvent, en interférant avec les technologies d'assistance natives, nuire à l'accessibilité des sites.
• La DINUM (Direction Interministérielle du Numérique) a confirmé cette position dans un article de référence : les outils de surcouche ne rendent ni accessible ni conforme.
• Le Forum européen des personnes handicapées a exprimé de vives préoccupations quant à leur usage.

Du côté des utilisateurs concernés, les chiffres parlent d'eux-mêmes : 67 % des professionnels de l'accessibilité estiment que ces outils sont peu ou pas du tout efficaces. Chez les personnes handicapées elles-mêmes, ce chiffre monte à 72 %.

La raison est technique : une surcouche agit par-dessus le code existant, sans corriger les erreurs à la source. Elle masque des problèmes structurels sans les résoudre, créant une fausse impression de conformité particulièrement dangereuse sur le plan juridique.

RGAA et WCAG : des référentiels pensés pour l'interprétation humaine

Le RGAA (Référentiel Général d'Amélioration de l'Accessibilité) est la déclinaison française officielle des normes WCAG 2.1 du W3C. Il définit 106 critères répartis en 13 thématiques (images, couleurs, tableaux, liens, scripts, formulaires, navigation, consultation…), avec trois niveaux de conformité : A, AA et AAA. La loi française exige le niveau AA.

Ce qui distingue fondamentalement le RGAA d'une simple checklist technique, c'est qu'une majorité de ses critères implique un jugement : est-ce que ce lien est suffisamment explicite ? Est-ce que cette alternative textuelle est pertinente dans ce contexte ? Est-ce que ce message d'alerte est correctement restitué par les technologies d'assistance utilisées réellement par les personnes concernées ?

Ces questions ne peuvent pas être posées à un algorithme. Elles requièrent une expertise et, idéalement, l'implication directe des utilisateurs pour lesquels l'accessibilité est une nécessité quotidienne.

Le RGAA 5, attendu fin 2026, devrait renforcer et affiner ces critères dans un contexte où l'European Accessibility Act s'applique désormais à la quasi-totalité des entreprises de plus de 10 salariés ou réalisant plus de 2 millions d'euros de chiffre d'affaires.

L'angle mort de tous les outils : les problèmes vécus, pas détectés

Il existe une catégorie entière de problèmes d'accessibilité que ni les audits automatisés ni même les meilleurs audits manuels ne peuvent systématiquement identifier : les difficultés vécues en conditions réelles par les utilisateurs.

Exemples concrets :

• Un utilisateur de lecteur d'écran signale qu'une notification dynamique (toast message) disparaît avant d'avoir été lue vocalement.
• Un utilisateur ayant des troubles moteurs rapporte qu'un menu déroulant est inutilisable uniquement sur mobile, avec un trackpad alternatif.
• Une personne dyslexique indique que la police choisie rend la lecture du contenu éditorial particulièrement pénible sur les pages longues.
• Un utilisateur malvoyant signale que l'interface fonctionne correctement avec le thème clair du système, mais que le mode sombre du site brise les contrastes.

Ces situations sont invisibles pour un outil automatisé. Elles sont souvent manquées par un audit ponctuel, réalisé dans des conditions standardisées qui ne reflètent pas toujours la diversité des configurations réelles (appareils, technologies d'assistance, préférences système, contextes d'usage).

C'est là qu'intervient un mécanisme que la plupart des organisations n'ont pas encore structuré : le signalement d'accessibilité par les utilisateurs eux-mêmes.

Du signalement utilisateur à l'amélioration continue : la voie complémentaire

L'accessibilité efficace ne se résume pas à un score obtenu lors d'un audit annuel. C'est un processus continu, nourri par des retours réels, exploitables et traçables.

C'est précisément dans cette logique qu'AIA Report a été conçu. La solution permet de recevoir et centraliser en temps réel les signalements d'accessibilité transmis directement par les utilisateurs, qu'ils soient clients, agents ou citoyens. Plutôt que d'analyser un site en isolation, AIA Report donne la parole aux personnes qui le vivent au quotidien.

Ces retours sont ensuite traduits en tâches exploitables, intégrées directement dans les outils de travail des équipes techniques : GitHub, GitLab, Jira, Trello ou Slack, selon le workflow en place. L'API ouverte permet également une intégration sur mesure dans n'importe quel environnement technique.

Ce modèle ne remplace pas les audits automatisés ou manuels, il les complète. Il permet de détecter les problèmes que les outils ne voient pas, de les prioriser selon leur impact réel sur les utilisateurs, et d'intégrer l'accessibilité comme une démarche vivante plutôt qu'une obligation documentaire ponctuelle.

L'étape suivante consiste généralement à structurer ces retours utilisateurs de manière exploitable par les équipes produit et techniques. C'est précisément ce que permet AIA Report : centraliser les signalements d'accessibilité, les qualifier, puis les transformer en tickets directement intégrables dans les outils de développement (GitHub, GitLab, Jira ou Trello).

Si vous souhaitez mettre en place ce type de boucle de feedback continue, vous pouvez découvrir AIA Report ici :

Ce qu'une stratégie d'accessibilité réaliste doit combiner en 2026

Pour être à la fois conforme et réellement inclusive, une démarche d'accessibilité numérique sérieuse doit articuler trois niveaux complémentaires :

Aucune de ces trois approches n'est suffisante seule. Ensemble, elles constituent le seul modèle capable de tenir la promesse d'un service numérique réellement accessible.

Conclusion

L'automatisation de l'accessibilité web n'est pas un problème de maturité technologique qui se résoudra dans les prochaines versions de l'IA. C'est une limite de nature, pas de degré. Les outils automatisés ne comprendront jamais le contexte éditorial d'une image, l'intention d'un lien, la frustration d'un utilisateur face à une modale mal restituée. Ces jugements nécessitent de l'expertise humaine et, plus fondamentalement, de l'écoute.

En 2026, face à la montée en charge des obligations légales (EAA, RGAA 5), la vraie question n'est plus "faut-il utiliser des outils automatisés ?". La réponse est oui, bien sûr. La vraie question est : comment organiser la complémentarité entre les outils, les experts et les utilisateurs pour bâtir une accessibilité qui tient dans la durée ?

FAQ : Questions fréquentes sur l'automatisation de l'accessibilité web