Overlays d'accessibilité et EAA : pourquoi un widget ne rend pas votre site conforme
Il y a un argument commercial qui est arrivé dans la boîte de réception de presque toutes les équipes web européennes depuis l'entrée en application de l'Acte européen sur l'accessibilité, le 28 juin 2025 : installez cette ligne de JavaScript et votre site sera conforme du jour au lendemain. Le produit est un overlay d'accessibilité, un widget placé dans un coin de la page qui propose un texte plus grand, un contraste renforcé, un « mode lecteur d'écran » et, dans les versions les plus ambitieuses, des textes alternatifs générés automatiquement.
Il vaut la peine d'être précis sur ce que font ces outils, car le risque se trouve dans l'écart entre la promesse et la réalité juridique.
Ce que change vraiment un overlay
Un overlay s'exécute après le chargement de la page, dans le navigateur du visiteur. Il peut modifier le style de ce qui existe déjà : agrandir le texte, inverser les couleurs, mettre en pause les animations, encadrer les liens. Certains tentent aussi de corriger le code à la volée, en devinant un texte alternatif pour une image qui n'en a pas ou en donnant à un bouton sans nom un libellé déduit de son icône.
Il en découle trois conséquences qui comptent pour l'EAA :
- Il ne modifie pas votre code. Le HTML envoyé par votre serveur est exactement aussi accessible, ou inaccessible, qu'avant. Chaque audit, chaque lecteur d'écran qui ne charge pas le widget, chaque robot d'indexation et chaque évaluation de conformité voit la page d'origine.
- Il ne sert qu'à ceux qui trouvent et utilisent le widget. La plupart des visiteurs handicapés arrivent avec leur propre technologie d'assistance déjà configurée : lecteur d'écran, plage braille, contacteur, loupe. Ils n'ont pas demandé une seconde couche inconnue par-dessus, et une plainte bien documentée dans cette communauté est que cette couche gêne les outils dont ils dépendent.
- Une supposition reste une supposition. Une machine qui nomme un bouton « Envoyer » « icône flèche » n'a pas rendu votre tunnel d'achat accessible. Elle a rendu l'erreur plus difficile à voir dans un rapport de test.
Ce que l'EAA demande à la place
La directive (UE) 2019/882 (en France, transposée par la loi du 9 mars 2023 dite DDADUE) ne parle ni de widgets, ni de badges, ni de fournisseurs. Elle fixe des exigences fonctionnelles d'accessibilité pour les produits et services concernés (commerce en ligne, services bancaires, transports, livres numériques, télécommunications, etc.) et renvoie à la norme harmonisée EN 301 549, qui pour les contenus web correspond aux critères de succès des WCAG 2.1 niveau AA.
Ces critères portent sur ce que vous publiez : chaque image a-t-elle une alternative textuelle, chaque champ de formulaire un nom, le parcours peut-il être mené au clavier de bout en bout, l'ordre du focus est-il logique, le contraste suffisant d'origine, les erreurs décrites par du texte. Ils portent aussi sur l'organisation : le service doit disposer d'une déclaration d'accessibilité, expliquer comment il se conforme, indiquer ce qui n'est pas encore conforme et donner un moyen de signaler les problèmes.
Les autorités de surveillance du marché de chaque État membre peuvent demander à un opérateur de démontrer sa conformité. La réponse attendue est une évaluation au regard de la norme et la documentation qui l'accompagne. « Nous avons installé un plugin » n'est pas une évaluation, et aucun fournisseur d'overlay ne signera votre déclaration à votre place.
L'EAA fait peser l'obligation sur l'opérateur économique. Vous pouvez sous-traiter les tests et les corrections. Vous ne pouvez pas sous-traiter la responsabilité à une balise script.
Les antécédents
Le marché des overlays s'est développé aux États-Unis, sous l'ADA, et c'est là que le recul est le plus long. Deux faits suffisent à le situer :
- Plusieurs années de suite, une part importante des procès pour accessibilité web intentés aux États-Unis visait des sites qui avaient déjà un overlay installé. Le widget n'a pas empêché la plainte, car la plainte portait sur le code en dessous.
- En janvier 2025, la Federal Trade Commission américaine (FTC) a ordonné à l'un des plus grands fournisseurs d'overlays de payer un million de dollars pour avoir affirmé que son produit pouvait rendre n'importe quel site conforme aux règles d'accessibilité. La FTC a conclu que ces affirmations n'étaient pas étayées.
Plus de huit cents professionnels de l'accessibilité, dont beaucoup sont eux-mêmes utilisateurs en situation de handicap, ont signé une déclaration publique demandant aux propriétaires de sites de ne pas s'appuyer sur les overlays. C'est un niveau d'accord rare dans un domaine qui débat de presque tout.
Quand un overlay n'est pas nuisible
Cela ne veut pas dire que les widgets ne servent à rien. Un visiteur sans technologie d'assistance qui veut simplement un texte plus grand sur un long article profite d'un réglage de taille de police. Si vous avez déjà un site accessible et que vous ajoutez un widget comme confort, le widget n'est pas le problème.
Le problème, c'est l'ordre. Le widget se pose sur un site accessible ; il ne le remplace pas. Si votre budget couvre soit l'abonnement à l'overlay, soit deux jours d'un développeur qui corrige les libellés et l'ordre du focus dans vos gabarits, seule la seconde option vous rapproche de la loi.
Que faire à la place
Une démarche pratique que nous voyons fonctionner chez les petits et moyens opérateurs :
- Auditez les vrais parcours, pas tout le site. Inscription, recherche, ajout au panier, paiement, contact. Testez chacun uniquement au clavier et avec un lecteur d'écran, puis lancez un scan automatique pour le reste. Les outils automatiques couvrent à peu près un tiers des critères ; le reste demande une personne.
- Corrigez dans les gabarits. Un composant corrigé répare toutes les pages qui l'utilisent, et le reste au déploiement suivant.
- Rédigez la déclaration d'accessibilité pendant que l'audit est frais : ce qui est conforme, ce qui ne l'est pas encore, pour quand, et comment signaler un problème. Publiez-la là où un visiteur la trouve en un clic.
- Intégrez l'accessibilité dans vos achats. Demandez à chaque fournisseur de composant, de thème ou de plugin ses propres preuves de conformité. C'est de là que viennent la plupart des régressions.
- Retestez à chaque version. Une courte liste dans le modèle de revue de code fait plus que n'importe quel audit annuel.
Si vous voulez une première lecture de l'état d'un site avant de décider quoi que ce soit, un scan automatique au regard de l'EN 301 549 est une première étape raisonnable, à condition que tout le monde comprenne que c'est le début de l'évaluation et non sa fin.