La promesse est séduisante : une ligne de JavaScript à coller dans votre page, et votre site deviendrait accessible sans audit ni reprise du produit. Une surcouche peut modifier certains éléments du rendu ou proposer des préférences d'affichage, mais elle ne peut pas, à elle seule, établir ni garantir la conformité d'un site. Voici pourquoi.
Ce qu'est une surcouche
Une surcouche, ou overlay, est un script tiers chargé sur vos pages. Il fait deux choses, qu'il faut distinguer parce qu'elles n'ont pas la même valeur.
D'abord, il ajoute une barre d'outils. Un bouton flottant, généralement en bas à droite, ouvre un panneau proposant d'augmenter la taille du texte, d'inverser les contrastes, de souligner les liens, de figer les animations, parfois d'activer une lecture vocale.
Ensuite, il tente de corriger la page à la volée. Le script parcourt le DOM après chargement et injecte ce qu'il croit manquant : des attributs ARIA, des rôles, des alternatives textuelles générées par reconnaissance d'image, des étiquettes de formulaire déduites du texte environnant.
C'est cette seconde partie qui porte souvent la promesse de conformité. Or une correction automatique ne peut traiter de façon fiable que les problèmes qu'elle sait détecter et dont la bonne solution ne dépend pas du contexte.
Pourquoi la correction automatique ne suffit pas
La correction dépend de l'exécution du script
Une surcouche modifie généralement le DOM rendu dans le navigateur sans corriger les composants, les gabarits ou les contenus à leur source. Ses effets dépendent donc du chargement du script, de sa compatibilité avec la page, des mises à jour du site et de son interaction avec les navigateurs et technologies d'assistance.
Un audit RGAA évalue le document et ses comportements tels qu'ils sont effectivement restitués à l'utilisateur ; une modification dynamique peut donc influer sur un résultat de test. Mais elle doit satisfaire tous les critères applicables, rester robuste dans les environnements de test et ne pas créer d'autres obstacles. Le simple fait d'installer une surcouche ne démontre rien de tout cela.
L'ARIA deviné aggrave souvent la situation
C'est le point le plus contre-intuitif pour les non-spécialistes. Un rôle ou un attribut ARIA incorrect peut produire une information trompeuse ou masquer une sémantique native utile. Le W3C recommande de préférer les éléments HTML natifs dès qu'ils offrent la sémantique et le comportement nécessaires.
// balisage d'origine, incorrect mais silencieux :- <div class="btn" onclick="envoyer()">Envoyer</div> // ce qu'une surcouche injecte :- <div class="btn" role="button" onclick="envoyer()">Envoyer</div> // le rôle est annoncé, mais l'élément n'est toujours pas // focalisable et ne réagit ni à Entrée ni à la barre d'espace // la vraie correction :+ <button type="button" class="btn" onclick="envoyer()">Envoyer</button>Annoncer un bouton qui ne se comporte pas comme un bouton crée une promesse non tenue pour l'utilisateur.
Le même raisonnement vaut pour les alternatives générées par reconnaissance d'image. Un modèle peut produire une description plausible, mais l'alternative pertinente dépend de la fonction de l'image et de son contexte. Une description comme « graphique en barres bleu » ne restitue pas les données du graphique. Une suggestion automatique doit donc être relue et validée par une personne qui comprend le contenu et son intention.
Le conflit avec les outils déjà en place
Les personnes concernées n'arrivent pas sur votre site les mains vides. Elles utilisent un lecteur d'écran configuré depuis des années, avec leurs raccourcis, leur vitesse de synthèse vocale, leurs habitudes de navigation. Elles ont réglé le contraste et la taille de police au niveau du système d'exploitation, pour tous les sites à la fois.
Une surcouche qui capture des raccourcis clavier ou réécrit le DOM pendant la navigation peut entrer en conflit avec cet outillage. Ce risque n'est pas systématique, mais il doit être testé avec les combinaisons de navigateurs et de technologies d'assistance prévues par l'audit, ainsi qu'avec de vrais parcours utilisateurs.
Ce que dit le cadre réglementaire
Le RGAA et les WCAG sont technologiquement neutres : ils n'approuvent ni n'interdisent une catégorie de produit. Ils évaluent des résultats vérifiables. Une surcouche pourrait donc contribuer à satisfaire un test précis si son effet est correct, robuste et disponible dans les conditions requises ; elle ne bénéficie d'aucune présomption générale de conformité.
Une barre d'outils peut être utile à certains utilisateurs, mais elle ne dispense d'aucun critère applicable. La déclaration d'accessibilité reste fondée sur une évaluation effective du service, et la responsabilité de l'organisme ne se transfère pas au fournisseur du script.
Ce qu'il faut faire à la place
La méthode qui fonctionne est moins spectaculaire, mais elle produit un résultat durable.
- Mesurer d'abord. Un pré-audit automatisé fournit des constats associés à une partie des critères RGAA et donne une cartographie par thème, avec les pages les plus touchées. Une revue humaine reste nécessaire pour conclure.
- Corriger à la source. Lorsqu'un défaut provient d'un composant mutualisé, le corriger dans ce composant peut résoudre toutes ses occurrences. Les contenus et cas particuliers doivent néanmoins être vérifiés séparément.
- Organiser la revue humaine. Les points dépendant du sens, du contexte, des parcours et de la restitution avec les technologies d'assistance doivent être testés manuellement.
- Surveiller ensuite. Des contrôles réguliers aident à détecter les régressions couvertes par leurs règles ; ils doivent être complétés par des vérifications manuelles périodiques.
Cette approche demande du travail, mais elle traite les causes, rend les corrections maintenables et permet de vérifier chaque exigence sur des bases explicites. Une ligne de JavaScript peut être un outil complémentaire ; elle ne remplace pas cette démarche.