Les outils d’audit automatique et les assistants de code ont transformé la manière d’aborder l’accessibilité numérique. À quelques mois de la publication du RGAA 5, ils n’ont pas supprimé le besoin d’expertise, ils l’ont déplacé.
Accessibilité numérique : de quoi parle-t-on exactement ?
Avant d’entrer dans le vif du sujet, cinq sigles reviennent en permanence dans cet article. Autant les poser d’emblée.
Concrètement, l’accessibilité numérique consiste à rendre un site ou une application utilisable par tout le monde, y compris par les personnes qui naviguent au clavier seul, à la commande vocale, à la loupe d’écran ou au lecteur d’écran — un logiciel qui restitue vocalement le contenu d’une interface. Ces technologies s’appellent les technologies d’assistance, et elles seront le fil rouge de cet article.
RGAA et European Accessibility Act : une obligation qui n’est plus théorique
Pendant quinze ans, l’accessibilité numérique est restée, pour beaucoup d’entreprises privées, un sujet de bonne conduite : souhaitable, rarement prioritaire, jamais contrôlé. Ce n’est plus le cas.
Depuis le 28 juin 2025, l’European Accessibility Act étend l’obligation d’accessibilité à un large périmètre d’acteurs privés : e-commerce, services bancaires, transport de voyageurs, télécommunications, livres numériques. En parallèle, le référentiel français s’apprête à changer de version. La DINUM annonce une publication du RGAA 5 pour fin 2026, avec trois évolutions majeures :
- l’alignement sur WCAG 2.2, la dernière version des recommandations internationales ;
- l’extension du référentiel aux applications mobiles et aux documents bureautiques, jusqu’ici hors périmètre ;
- la désignation de l’Arcom comme autorité de contrôle.
Deux échéances, dont une déjà passée.
Précision importante : le RGAA 4.1.2 reste la référence en vigueur d’ici là. Les audits engagés aujourd’hui conservent toute leur valeur et n’ont aucune raison d’être suspendus en attendant la nouvelle version.
Autrement dit : le périmètre s’élargit, le contrôle se structure, et les échéances se rapprochent. Face à cette pression, une promesse séduisante circule : celle de l’automatisation. Un scan, un correctif, une ligne de JavaScript, et le problème serait réglé.
La réalité est plus nuancée. L’IA et les outils d’audit automatique apportent un gain réel et mesurable. Mais ils traitent la partie la plus simple du problème, et laissent intacte celle qui détermine si votre site est utilisable ou non.
Ce que l’IA et les outils d’audit d’accessibilité font vraiment bien
Commençons par ce qui fonctionne, parce que c’est substantiel.
La détection automatique est devenue excellente sur les erreurs de syntaxe. Des outils comme axe, Lighthouse ou Wave identifient en quelques secondes un contraste insuffisant, un attribut lang manquant, un champ de formulaire sans étiquette, une image sans attribut alt, une structure de tableau incorrecte. Ces vérifications sont fiables, reproductibles, et surtout intégrables dans une chaîne d’intégration continue. Une régression d’accessibilité peut aujourd’hui faire échouer une pull request au même titre qu’un test unitaire. C’est un changement de nature : on passe d’un audit ponctuel et coûteux à un garde-fou permanent et gratuit.
Les assistants de code ont relevé le niveau de base. Demandez aujourd’hui un composant d’onglets ou une fenêtre modale à un assistant sérieux : vous obtiendrez du markup sémantique, des rôles ARIA cohérents, une gestion clavier esquissée. Un développeur qui ne connaît pas le RGAA produit désormais, par défaut, du code plus accessible qu’il y a trois ans. C’est un progrès collectif considérable, et il faut le reconnaître sans réserve.
L’IA est aussi un formidable outil pédagogique. Expliquer un critère RGAA, traduire une exigence WCAG en implémentation concrète, proposer trois formulations d’un texte alternatif : ce sont des tâches où l’assistance conversationnelle fait gagner un temps considérable à des équipes qui découvrent le sujet.
Le gain est donc réel. Il porte sur le coût du premier passage et sur la diffusion de la connaissance. Ce n’est pas rien.
Les limites de l’IA en accessibilité : ce qu’aucun outil automatique ne détecte
Le problème commence quand on confond « aucune erreur détectée » avec « accessible ». Ce sont deux affirmations très différentes, et l’écart entre elles est précisément l’endroit où vit l’expertise.
La présence n’est pas la pertinence
Un alt="graphique" satisfait tous les validateurs automatiques du marché. Il n’apporte strictement rien à l’utilisateur. Une IA multimodale décrira correctement ce qu’elle voit sur l’image mais elle ne sait pas pourquoi cette image est là, quelle information elle porte dans le contexte éditorial de la page, ni si elle est purement décorative. Ce jugement est contextuel, donc humain.
Les parcours ne se testent pas sur un DOM figé
Prenez une fenêtre modale. Le code peut être irréprochable à l’analyse statique :
<div role="dialog" aria-modal="true" aria-labelledby="titre-modale">
<h2 id="titre-modale">Confirmer la suppression</h2>
...
</div>
Tous les tests passent. Et pourtant : le focus est-il déplacé dans la modale à l’ouverture ? Est-il piégé à l’intérieur tant qu’elle est ouverte ? Revient-il sur l’élément déclencheur à la fermeture ? La touche Échap fonctionne-t-elle ? Le contenu derrière est-il correctement masqué aux technologies d’assistance ? Aucune de ces questions n’a de réponse dans le HTML. Elles ne se vérifient qu’en interagissant réellement avec le composant.
Le même composant, vu par un validateur et vu par un utilisateur.
Le même raisonnement vaut pour la navigation dans une application monopage, où le changement de vue ne provoque aucun rechargement et donc, par défaut, aucune annonce au lecteur d’écran.
L’accessibilité a une dimension temporelle
Un message d’erreur de formulaire est-il annoncé ? Au bon moment ? Une seule fois ? Un aria-live mal positionné produit soit le silence, soit un bavardage ininterrompu qui rend l’interface inutilisable. Un scan statique ne perçoit pas cette dimension.
Le nom accessible peut diverger du libellé visible
Un bouton affichant « Envoyer » mais portant un aria-label="Soumettre le formulaire" est valide pour un validateur. Il est inutilisable en commande vocale : l’utilisateur dit « cliquer sur Envoyer », et rien ne se passe.
Certains composants sont « ARIA-corrects » et fonctionnellement cassés
Les rôles sont justes, la structure est conforme, mais la navigation clavier ne respecte pas le modèle d’interaction attendu : les flèches ne parcourent pas la liste, Home et End ne font rien, le comportement diffère de ce que l’utilisateur a appris ailleurs.
Le référentiel lui-même en tire les conséquences : le RGAA repose sur une centaine de critères dont une large majorité exige une vérification humaine, et la conformité se déclare sur un échantillon de pages réellement testées, pas sur le score d’un outil.
Overlays d’accessibilité : pourquoi ils ne suffisent pas à la conformité RGAA
Depuis l’entrée en vigueur de l’European Accessibility Act, un marché s’est développé autour de solutions promettant la conformité via l’insertion d’un unique script, ce qu’on appelle des overlays. Le discours commercial est efficace : pas de refonte, pas d’audit, pas de dette technique à reprendre.
La communauté de l’accessibilité (développeurs spécialisés, associations d’utilisateurs, experts du domaine) s’y oppose de manière largement documentée. Les raisons de fond sont simples : une surcouche exécutée côté client ne peut pas deviner l’intention éditoriale d’une image, ne répare pas un parcours défaillant, et entre fréquemment en conflit avec les réglages personnels de l’utilisateur, qui a déjà configuré son lecteur d’écran comme il le souhaite.
Sur le plan réglementaire, le point est encore plus direct : une déclaration de conformité RGAA s’appuie sur un audit de critères, mené sur un échantillon de pages. Un overlay ne produit pas cet audit. Il ne peut donc pas, à lui seul, fonder la déclaration.
Méthode d’audit RGAA : trois couches, pas une
Ce n’est pas un plaidoyer contre l’automatisation. C’est un plaidoyer pour la mettre à sa place : la première, pas la dernière.
Chaque couche attrape ce que la précédente ne peut pas voir.
Couche 1 : L’automatisation, en continu. Linters d’accessibilité dans l’éditeur, tests automatisés dans la chaîne d’intégration continue. Objectif : que les erreurs triviales n’atteignent jamais la revue de code. C’est là que l’outillage et l’IA donnent leur maximum, et c’est du temps d’expert libéré.
Couche 2 : La revue humaine des critères à jugement. Pertinence des alternatives textuelles, cohérence de la hiérarchie des titres avec la structure réelle du contenu, intelligibilité des libellés de liens hors contexte, logique de l’ordre de tabulation. Un expert accompagné d’une IA va vite ici mais c’est l’expert qui tranche.
Couche 3 : Le test réel, avec les outils des utilisateurs. Navigation au clavier seul, sans souris, sur l’ensemble des parcours critiques. Puis test au lecteur d’écran, sur au moins deux combinaisons de référence : NVDA avec Firefox, VoiceOver avec Safari, et TalkBack sur mobile si une application est concernée.
C’est cette troisième couche qui est systématiquement sacrifiée, et c’est la seule qui réponde à la seule question qui compte : est-ce que quelqu’un peut réellement utiliser ce service ? Dix minutes passées à écouter une page révèlent des problèmes qu’aucun rapport automatique ne remontera jamais. Et lorsque le contexte le permet, le test avec des utilisateurs en situation de handicap reste l’étalon-or, rien ne le remplace.
RGAA 5 et IA : ce qui change pour les équipes techniques
L’IA ne supprime pas le métier de l’accessibilité. Elle en retire la partie mécanique (chercher les erreurs triviales, réciter les critères, produire le markup de base) et laisse intacte la partie difficile : juger de la pertinence, arbitrer entre contraintes, tester réellement, former les équipes, tenir la conformité dans la durée.
C’est une montée en valeur, pas une menace. Mais elle suppose d’assumer une chose : un rapport vert n’est pas une preuve d’accessibilité, c’est une preuve d’absence d’erreurs détectables automatiquement.
Le RGAA 5 va rendre ce point encore plus sensible. Les deux périmètres qu’il ajoute : applications mobiles et documents bureautiques, sont précisément ceux où l’outillage automatique est aujourd’hui le plus faible et où le test manuel est le plus incontournable. Les organisations qui auront construit une vraie compétence interne, outillée mais pas dépendante de l’outil, aborderont cette échéance sereinement. Les autres découvriront que leur score parfait ne valait rien.
Besoin d’accompagnement sur votre conformité RGAA ?
L’échéance du RGAA 5 approche, et l’European Accessibility Act s’applique déjà. Que vous partiez d’une page blanche ou d’un audit à reprendre, les experts skiils vous accompagnent sur toute la chaîne :
- Audit de conformité RGAA sur un échantillon représentatif, avec test au lecteur d’écran et restitution priorisée ;
- Mise en conformité : reprise des composants, correction des parcours critiques, rédaction de la déclaration d’accessibilité ;
- Industrialisation : intégration des tests d’accessibilité dans votre chaîne CI, pour que la conformité tienne dans la durée ;
- Formation et montée en compétence de vos équipes de développement et de design.
👉 Parlons de votre projet : nos experts vous répondent.
