« On a vu un plugin qui règle l’accessibilité en collant juste un script, ça coûte trois fois moins cher que votre audit » : cette remarque d’un prospect, lors d’un rendez-vous commercial, résume bien la promesse des overlays d’accessibilité, ces widgets tiers qui s’installent en une ligne de JavaScript et affichent un petit panneau flottant proposant d’agrandir le texte, de changer les contrastes, ou d’activer un « mode lecteur d’écran ». La promesse commerciale est séduisante. La réalité technique l’est beaucoup moins, et mérite d’être expliquée précisément plutôt que rejetée d’un revers de main.
Un overlay n’est ni une arnaque totale ni une solution miracle : c’est un outil qui corrige un nombre limité de problèmes de surface, tout en donnant l’impression trompeuse d’une conformité globale qu’il ne peut techniquement pas garantir.
Ce qu’un overlay peut effectivement corriger
Certains réglages proposés par ces widgets ont une valeur réelle et immédiate pour l’utilisateur qui les active volontairement : augmenter la taille du texte, renforcer les contrastes visuels, activer un curseur agrandi, ou désactiver les animations. Ces réglages, appliqués en CSS par-dessus le site existant, fonctionnent effectivement pour l’utilisateur qui prend la peine d’ouvrir le panneau et de les activer.
Ce qu’un overlay ne peut techniquement pas corriger
Le problème central tient à la nature même du HTML sous-jacent. Un script tiers, injecté après le chargement de la page, ne peut pas :
- Ajouter un texte alternatif pertinent à une image dont il ne connaît pas le contenu réel — au mieux, il génère une description automatique par reconnaissance d’image, souvent approximative ou carrément erronée.
- Corriger un ordre de tabulation incohérent, qui dépend de la structure du DOM elle-même, pas d’une couche visuelle ajoutée par-dessus.
- Réparer un composant JavaScript interactif mal codé (un accordéon sans gestion clavier, par exemple) sans reconstruire entièrement son comportement, ce qu’un overlay générique ne fait jamais composant par composant.
- Garantir qu’un formulaire annonce correctement ses erreurs, puisque cela dépend de la structure et des attributs posés à la source par le développeur du site.
Le risque le plus documenté : bloquer les technologies réelles
Plusieurs retours d’expérience publiés par des utilisateurs de lecteurs d’écran ou de logiciels de reconnaissance vocale rapportent un effet inverse à celui recherché : certains overlays interceptent les événements clavier ou modifient le DOM d’une façon qui perturbe le fonctionnement normal des vraies technologies d’assistance déjà installées sur l’ordinateur de l’utilisateur — NVDA, JAWS ou VoiceOver. Un utilisateur qui a déjà configuré son propre outil, souvent depuis des années, se retrouve alors avec un comportement dégradé plutôt qu’amélioré, à cause d’une couche logicielle qu’il n’a pas choisie et ne peut pas désactiver facilement.
Le risque juridique, à l’inverse de la promesse commerciale
Aux États-Unis, plusieurs procédures judiciaires ont visé des sites équipés d’un overlay, sans que sa seule présence n’ait suffi à écarter la plainte : la conformité s’évalue sur le résultat réel constaté par un utilisateur, pas sur l’installation d’un outil supposé la garantir. En France, le RGAA fonctionne sur le même principe : une déclaration d’accessibilité s’appuie sur un audit documenté du site réel, pas sur la présence d’un widget commercial.
Ce que nous recommandons à la place
Un overlay peut rester en place comme complément de confort pour les visiteurs qui l’utilisent volontairement, mais il ne remplace jamais le travail à la source : structure HTML correcte, contrastes respectés dans le design, composants interactifs testés au clavier et au lecteur d’écran.
Pour ce client, la proposition finale a écarté l’overlay au profit d’un audit RGAA classique suivi de corrections directement dans le thème, plus coûteux à court terme mais seul à réellement améliorer l’expérience des utilisateurs de technologies d’assistance existantes, plutôt que de leur imposer une couche supplémentaire non désirée.
En résumé
Un overlay d’accessibilité n’est pas nécessairement inutile, mais il traite des symptômes de surface sans jamais toucher à la cause : le code source du site. La seule façon de savoir ce qu’il masque plutôt que corrige est de tester le site sans lui, avec un vrai lecteur d’écran et une navigation au clavier complète — un audit que nous détaillons dans un prochain article dédié.
