Nous avons intercepté toutes les requêtes provenant de cinq outils d'accessibilité. Voici ce qu'ils font réellement à votre site.

Un audit technique indépendant portant sur quatre superpositions d'accessibilité et une solution de surveillance uniquement : ce qu'elles modifient réellement, ce qu'elles cachent aux utilisateurs en situation de handicap, et pourquoi plus de 1 000 entreprises utilisant des superpositions ont été poursuivies en justice rien qu'en 2024.

Comment nous avons procédé : la méthodologie de recherche

La plupart des analyses consacrées aux superpositions d'accessibilité s'appuient sur des arguments marketing, la documentation des fournisseurs ou des tests superficiels. Nous avons adopté une approche radicalement différente : nous avons intercepté chaque octet de données transitant entre le navigateur et les serveurs de chaque outil, extrait les fichiers de correction JavaScript et les données de correction réels, puis analysé précisément ce que chaque outil fait au DOM en temps réel des sites de commerce électronique en production.

La configuration technique

Nous avons déployé mitmproxy – un proxy HTTPS open source – configuré pour capturer l'intégralité du corps des requêtes et des réponses pour tout le trafic destiné aux domaines CDN et API des outils. Nous avons installé le certificat d'autorité de certification racine du proxy dans le navigateur afin de permettre une interception HTTPS transparente, puis nous avons lancé une instance Chrome dédiée acheminée exclusivement via le proxy. Nous avons configuré des filtres de domaine afin de ne capturer que le trafic destiné aux serveurs des outils d'accessibilité, garantissant ainsi que nous n'analysions que ce que ces outils injectaient, et non le trafic propre aux sites.

Nous avons ensuite parcouru 14 sites de commerce électronique en ligne comme le ferait un utilisateur lambda : chargement de la page d'accueil, navigation vers les pages de liste de produits, consultation des pages de détails des produits, ajout d'articles au panier, passage à la caisse, consultation des pages de compte et d'inscription, et interaction avec les fenêtres modales, les carrousels et la fonction de recherche. Chaque session de navigation a été enregistrée sous forme de fichier HTTP Archive (HAR) contenant l'intégralité des corps de réponse – le même format que celui utilisé en interne par les navigateurs, mais enrichi du contenu réel de chaque fichier JavaScript, de chaque feuille de style CSS, de chaque configuration JSON et de chaque réponse API fournie par les outils.

Une fois les données collectées, nous avons écrit des scripts d'analyse en Python qui ont analysé le corps de chaque réponse, classé chaque fichier par outil et par fonction, extrait tous les sélecteurs CSS des définitions de correction, recensé tous les modèles de manipulation du DOM dans le code JavaScript, identifié tous les cas où du contenu était masqué aux technologies d'assistance, et associé chaque correction à la zone de la page qu'elle concernait (paiement, panier, liste de produits, navigation, etc.).

Le proxy a capturé 924 requêtes HTTP avec 579 corps de réponse complets au cours de trois sessions de capture, y compris chaque script de correction par site, chaque fichier JSON de correction, chaque fichier de configuration et chaque charge utile d'analyse. Nous avons également enregistré des instantanés DOM complets des pages avec les modifications superposées appliquées, ce qui nous a permis d'inspecter les valeurs exactes des balises aria-label et les attributs de données des fournisseurs injectés lors de l'exécution. Nous avons ensuite écrit des scripts d'analyse automatisés pour analyser le JavaScript, compter chaque modèle de modification DOM, extraire chaque sélecteur CSS, classer chaque correction par zone de page et identifier chaque instance de contenu masqué aux technologies d'assistance.

Ce que nous avons analysé

Ces sites concernaient de grands détaillants de mode, des marques de chocolat de luxe, des fabricants de bagages, des boutiques de sacs à main de créateurs, des fabricants de jouets, un opérateur de télécommunications, une banque nationale, ainsi que des marques de boissons, d'articles de papeterie, de montres et de confiserie, couvrant à la fois les marchés de l'Union européenne et des États-Unis.

Remarque importante : aucune portée au niveau de la page dans aucune interface d'accessibilité

L'une des conclusions les plus surprenantes est apparue avant même que nous ayons analysé les règles de correction : chaque superposition d'accessibilité charge l'intégralité de son ensemble de corrections sur chaque page, quel que soit le type de page. Les corrections spécifiques au processus de paiement s'appliquent sur la page d'accueil. Les règles relatives à la quantité dans le panier s'appliquent sur la page « À propos de nous ». Les corrections concernant les vignettes de produits s'appliquent sur le formulaire de connexion.

Cela signifie que sur le site de l'opérateur télécom, chaque visiteur de chaque page télécharge un fichier JSON de 1,25 Mo contenant 4 974 descriptions d'images et 2 000 entrées de correction au format PDF, même sur les pages ne comportant aucune image. Sur le site du détaillant de sacs à main de créateurs, 383 règles de correction DOM s’exécutent à chaque chargement de page, tentant de faire correspondre des sélecteurs qui n’existent que sur des types de pages spécifiques. Lorsqu’un sélecteur spécifique à la page de paiement, tel que #cardNumber, ne trouve pas de correspondance sur la page d’accueil, le moteur de correction de l’overlay continue de consommer des cycles CPU pour l’évaluer. Multiplié par des centaines de règles, cela entraîne une perte de performances mesurable à chaque consultation de page.

La superposition A ne couvre que 4,5 % des sessions

En fouillant dans les données POST issues des analyses d'Overlay A, nous avons découvert un champ indiquant son taux d'échantillonnage réel lors de l'analyse :

Un taux d'échantillonnage de 0,045 signifie que seules 4,5 % des sessions des visiteurs déclenchent une analyse de conformité sur ce site de vente en ligne de mode. Sur un autre site – celui d'une marque de chocolats de luxe –, ce taux était encore plus faible : à peine 1,7 %. Il est possible que le fournisseur de la solution de superposition effectue une analyse initiale plus approfondie lors de la mise en place ou de la configuration, puis réduise le taux d'échantillonnage pour la surveillance continue. Toutefois, les implications pour les opérations quotidiennes restent importantes.

Le code du module de démarrage de la superposition d'accessibilité confirme l'existence de trois niveaux de fonctionnement : ReleaseVersionReport (analyse complète + rapport – pourcentage échantillonné), ShadowVersionReport (analyse en arrière-plan, aucune action visible pour l'utilisateur) et RunReleaseFixesNoReport (application de toutes les règles de correction sans exécution d'analyse). Cela signifie qu'en fonctionnement normal, la grande majorité de vos visiteurs reçoivent des modifications du DOM qui ne sont pas validées au cours de leur session.

Le risque concret est le suivant : si le déploiement d'un site modifie la structure du DOM et enfreint une ou plusieurs règles de correction, le faible taux d'échantillonnage continu signifie que la régression peut passer inaperçue pendant une longue période. Avec seulement 1,7 à 4,5 % des sessions analysées, une correction défaillante pourrait affecter des milliers de visiteurs avant que la prochaine session échantillonnée ne se déclenche sur la page concernée et ne signale le problème. Pendant ce laps de temps, chaque visiteur reçoit des corrections obsolètes ou mal ciblées, et ni l'exploitant du site ni le fournisseur de la superposition ne sont nécessairement conscients du problème.

Conclusions : correction des règles et des modifications du DOM

Superposition A : fichiers de correction JavaScript par site

Cette superposition gère un fichier de correction JavaScript distinct pour chaque site client, contenant des règles qui ciblent des sélecteurs CSS spécifiques. Sur les cinq sites que nous avons analysés, nous avons constaté :

Nous avons également constaté 7 cas là où la chaîne littérale "true" a été injecté sous forme de aria-label – un bug de code dans lequel une valeur booléenne a été transmise à la place d'un texte descriptif. Les lecteurs d'écran annoncent « bouton, vrai », ce qui n'a absolument aucun sens. Sur un autre site, le mot « Search » était mal orthographié (« Seacrh ») dans une étiquette insérée.

Superposition B : texte alternatif généré par l'IA à grande échelle

Cette superposition télécharge d'énormes fichiers JSON de correction contenant des descriptions d'images générées par l'IA. Sur trois sites :

Exemples concrets tirés des données de remise en état :

323 descriptions dépassaient 125 caractères, ce qui entraînait une lecture trop détaillée par les lecteurs d'écran, ceux-ci passant 10 à 15 secondes sur chaque image. 156 commençaient inutilement par « image de », ce qui constitue un anti-modèle selon les WCAG, puisque les lecteurs d'écran indiquent déjà le type d'élément.

Outil de surveillance : aucune modification – vérifié dans le code source

Ce que signifie « Masquer pour AT » pour les utilisateurs réels

Lorsqu'une superposition masque un élément aux technologies d'assistance, celui-ci reste visible à l'écran mais devient totalement invisible pour les lecteurs d'écran. Nous avons classé chaque élément masqué en fonction de la zone de la page qu'il affecte :

Données issues des fichiers de correction active.js réels, extraites site par site à l'aide de mitmproxy. Chaque valeur correspond à un sélecteur CSS unique ciblé par la fonction hideFromAT().

Sur la page de paiement d'un site de vente en ligne de luxe, les éléments masqués aux lecteurs d'écran comprenaient :

Voici comment les outils de superposition d'accessibilité créent une expérience d'achat à deux vitesses: les utilisateurs voyants voient toutes les options de paiement et peuvent choisir entre la carte de crédit, PayPal, Amazon Pay, Shop Pay et Klarna. Les utilisateurs aveugles ne peuvent accéder qu'aux modes de paiement que la superposition n'a pas masqués. Sur le site d'un détaillant de mode, le champ de saisie de la quantité dans le panier et le bouton de mise à jour étaient tous deux masqués : un utilisateur aveugle pouvait ajouter des articles, mais ne pouvait pas modifier les quantités.

Cela soulève une question fondamentale : un volet qui masque les boutons de paiement aux utilisateurs aveugles rend-il le site plus accessible ou moins accessible ?

Impact sur les performances

Que se passe-t-il après le déploiement d'un site ?

Le risque le plus insidieux lié aux outils de superposition ne se révèle peut-être qu'avec le temps : les corrections se dégradent en silence. Contrairement à une erreur JavaScript qui provoque un plantage visible ou à une mise en page défectueuse que quelqu'un remarque, une correction de superposition obsolète ne génère aucune erreur, aucune alerte et aucun changement visuel. Elle cesse simplement de fonctionner – et l'obstacle à l'accessibilité qu'elle masquait réapparaît sans que personne ne s'en aperçoive.

Pour bien comprendre cela, examinez comment chaque type de superposition s'intègre à la structure DOM de votre site.

Corrections basées sur les sélecteurs : le temps presse

Overlay A – comme la plupart des solutions de superposition pour l'accessibilité – gère des fichiers de correction JavaScript spécifiques à chaque site, contenant des règles telles que celle-ci (reconstituée à partir du code capturé) :

Cette règle cible le bouton fléché « Précédent » d'un carrousel Slick à l'aide de trois classes CSS : .js-recommendation_carousel, .slick-prev, et .slick-arrow. Chaque élément de ce sélecteur est fragile. Si l'équipe chargée du site renomme la classe du conteneur du carrousel, passe de Slick à Splide ou Swiper, ou met simplement à jour la bibliothèque Slick vers une version qui modifie la convention de nommage des classes, le sélecteur ne correspond plus à rien. Le bouton perd son libellé « Diapositive précédente ». Les utilisateurs de lecteurs d'écran ne peuvent plus l'identifier.

Sur les cinq sites que nous avons analysés pour la superposition A, nous avons constaté 98 % de tous les sélecteurs contiennent des noms de classes propres à un framework – les classes dont le nom commence par .js-, .b-, .chakra-, .splide__, ou des hachages CSS-in-JS tels que .css-acuo7n. Il ne s'agit pas d'identificateurs sémantiques stables, mais de détails d'implémentation qui changent à chaque mise à jour du framework, refactorisation de composant ou modification du système de compilation.

Sur le site d’un détaillant de sacs à main de créateurs, nous avons découvert des sélecteurs ciblant des composants de l’interface utilisateur Chakra. Les versions majeures de Chakra UI introduisent des changements incompatibles : les noms de classes, la structure des composants et les modèles ARIA évoluent tous. Lorsque ce site mettra à jour Chakra, des centaines de règles de correction de superposition risquent de cesser de fonctionner sans que cela soit signalé. Le fournisseur de superposition doit alors vérifier manuellement la nouvelle structure DOM, réécrire chaque sélecteur affecté et déployer les fichiers de correction mis à jour. Pendant le délai entre le déploiement du site et la mise à jour du fournisseur de superposition, le site fonctionne avec des corrections obsolètes : certaines ne font rien, d’autres s’appliquent potentiellement aux mauvais éléments.

Corrections basées sur les URL : encore plus fragiles

Le script Overlay B remplace, à l'aide de clés JSON, chaque entrée de texte alternatif par l'URL exacte de la source de l'image. Nous avons trouvé des entrées telles que :

Remarquez la fragilité : l'URL contient un identifiant d'appareil (13555), une taille de vignette (86x86), ainsi qu'un nom de fichier comprenant le nom du produit. Ces éléments peuvent évoluer indépendamment les uns des autres. Si le CMS régénère les vignettes dans un format différent, le thumb_86x86 Une partie de l'URL change et l'entrée ne correspond plus. Si l'équipe produit télécharge une nouvelle photo avec un nom de fichier différent, l'entrée devient orpheline. Si le site migre ses médias vers un CDN avec un domaine différent, chaque entrée du fichier JSON de 1,17 Mo devient un poids mort – et toutes les images du site perdent simultanément leur texte alternatif.

Le pire scénario est un échec partiel de la correspondance : certaines images conservent leurs anciennes URL (et reçoivent un texte alternatif), tandis que les images nouvelles ou mises à jour ne correspondent à aucune entrée (et ne reçoivent rien). Il en résulte une expérience incohérente où certaines images sont décrites et d'autres sont ignorées sans avertissement – ce qui est bien plus déroutant pour un utilisateur de lecteur d'écran qu'une absence systématique de texte alternatif.

Corrections à l'échelle mondiale : le problème de la cascade

L'approche d'Overlay C : associer un MutationObserver à l'ensemble du document et appliquer des corrections génériques à tous les éléments de certains types (a, button, input, img, h1) – entraîne un type de dysfonctionnement différent, mais tout aussi dangereux. Au lieu de tomber en panne sans signe avant-coureur lorsque les sélecteurs deviennent obsolètes, cette superposition s'attaque activement au nouveau code.

Prenons un scénario courant : l'équipe du site déploie un nouveau composant de boîte de dialogue modale accessible qui implémente correctement le « focus trapping », la fermeture par la touche Échap et les attributs ARIA. Le MutationObserver de la superposition détecte les nouveaux éléments DOM, les évalue par rapport à ses règles génériques et, lorsqu'il trouve des éléments correspondant à ses modèles, applique sa propre gestion du focus, ses propres gestionnaires de clavier et ses propres attributs ARIA par-dessus l'implémentation existante et correcte du composant. Il en résulte un focus doublement capturé, des gestionnaires de clavier en double et des attributs ARIA conflictuels. La fenêtre modale qui fonctionnait parfaitement avant le chargement de la superposition se comporte désormais de manière erratique.

Il ne s'agit pas là d'une préoccupation purement théorique. Les bibliothèques de composants de framework telles que Radix UI, Headless UI et Chakra UI consacrent d'importants efforts d'ingénierie à la mise en œuvre correcte d'ARIA. Une superposition qui applique systématiquement ses propres attributs ARIA à tous les button et a ces éléments risquent d'entrer en conflit avec ces implémentations éprouvées, ce qui rendra les composants difficilement accessibles moins accessible.

L'outil de surveillance : rien à casser

L'outil de surveillance que nous avons analysé ne comporte ni correctifs basés sur des sélecteurs, ni entrées liées à des URL, ni MutationObserver, ni ciblage générique d'éléments. Lorsque le site déploie un nouveau code, la prochaine analyse de l'outil de surveillance évalue automatiquement le nouveau DOM par rapport à l'ensemble de règles standardisées d'axe-core et signale toute nouvelle violation, sans rien modifier. Les résultats de l'analyse s'affichent dans le tableau de bord de l'outil avec les niveaux de gravité, le nombre d'éléments affectés et les identifiants de règles WCAG standardisés. Les développeurs examinent les résultats et implémentent les corrections dans leur propre base de code, où celles-ci sont soumises à une révision du code, à des tests automatisés, à une validation en environnement de préproduction et à un déploiement contrôlé.

Ce processus est intrinsèquement résilient face au changement : l'outil analyse le DOM tel qu'il se présente au moment de l'analyse, signale les problèmes détectés, puis repart de zéro lors de l'analyse suivante. Il n'y a pas d'accumulation de dette technique liée aux définitions de corrections, pas de sélecteurs obsolètes, pas d'entrées de texte alternatif orphelines, et aucune possibilité d'appliquer une correction inappropriée à un élément erroné.

Qu'est-ce qui ne fonctionne plus lors d'un redéploiement ?

Chaque correction apportée à la couche d'accessibilité est liée à la structure DOM actuelle du site. Nous avons constaté que 98 % des sélecteurs d'une superposition ciblent des noms de classes propres au framework – des cours tels que .chakra-, .splide__, .js-, .b-, ainsi que les hachages CSS-in-JS tels que .css-acuo7n qui changent à chaque compilation.

L'outil de surveillance affiche « Non affecté » dans chaque ligne, car il ne contient aucune correction basée sur un sélecteur. Il n'y a donc rien qui puisse devenir obsolète, rien qui puisse cibler le mauvais élément, rien qui puisse causer une erreur.

Le RGPD, la protection de la vie privée et la question du consentement

Notre analyse a confirmé que trois des quatre fenêtres contextuelles d'accessibilité envoient des données à des serveurs externes avant même que l'utilisateur puisse interagir avec la bannière de consentement :

Conformément à l'arrêt « Planet49 » de la CJUE, le suivi non essentiel nécessite un consentement préalable exprès. Deux fenêtres contextuelles transmettent des identifiants persistants dès la première requête réseau, avant même que tout mécanisme de consentement ne puisse s'activer. Pour les sites destinés à l'UE, cela constitue automatiquement une non-conformité au RGPD.

Le contexte juridique

En avril 2025, la Commission fédérale du commerce des États-Unis (FTC) a conclu un accord à l'amiable d'un million de dollars avec l'un des fournisseurs de solutions d'accessibilité de notre étude, pour avoir prétendu à tort que son outil basé sur l'IA pouvait rendre n'importe quel site web conforme aux WCAG. La FTC a constaté que l'outil ne parvenait pas à rendre accessibles les éléments de base d'un site web : menus, titres, tableaux, images et enregistrements. Dans un exemple cité, une photo de filet mignon avait reçu la description générée par l'IA suivante : « Pain complet sur une assiette en céramique blanche ».

Selon les données de suivi du secteur, 25 % de toutes les poursuites judiciaires relatives à l'accessibilité numérique en 2024 citaient explicitement les widgets de superposition comme des obstacles – et non comme des solutions. Au cours du premier semestre 2025, les poursuites contre les entreprises utilisant des superpositions se sont poursuivies à un rythme de plus de 100 par mois. Deux des fournisseurs de superpositions étudiés dans notre enquête ont été directement impliqués dans des litiges : l'un dans trois affaires distinctes relatives à des brevets ou à des secrets d'affaires, et l'autre dans le cadre d'un recours collectif intenté par une petite entreprise cliente qui a été poursuivie en justice bien qu'elle ait utilisé la superposition.

L'outil de surveillance utilisé dans notre étude n'a fait l'objet d'aucun litige lié à des problèmes d'accessibilité – une conséquence logique de son architecture : comme il ne modifie jamais le DOM, il ne peut pas créer d'obstacles à l'accessibilité.

Dans les coulisses du code : ce que modifient réellement les superpositions

Pour saisir l'ampleur de la manipulation du DOM, nous avons recensé tous les schémas de modification présents dans le code JavaScript de chaque outil. Les différences sont frappantes :

Overlay C mérite une attention particulière. Son ensemble monolithique de 794 Ko intègre un MutationObserver à document.documentElement avec la configuration {subtree: true, childList: true, attributes: true, attributeOldValue: true}. Cela signifie chaque modification du DOM sur l'ensemble de la page – qu'il s'agisse de la réconciliation du DOM virtuel de React, d'un script de test A/B, d'un widget de chat ou du propre code JavaScript du site – déclenche l'observateur de la superposition, qui réévalue alors les éléments et peut réappliquer ses corrections. Après un redéploiement du site, cela entraîne une cascade de tentatives de correction sur des éléments qui sont peut-être déjà correctement accessibles, ce qui risque de remplacer les attributs ARIA corrects par des attributs erronés.

Nous avons vérifié qu'Overlay C envoie USER-BEHAVIOR-ANALYTICS Envoie des requêtes POST à son propre récepteur de journaux, avec des données contenant le domaine du site, la version du widget, la langue de l'utilisateur et les événements d'interaction. Associé à localStorage persistance et identification des appareils via navigator.userAgent et navigator.maxTouchPointsCela correspond à un traitement de données dont la plupart des exploitants de sites ignorent l'existence.

Le problème du fichier JSON de correction

Overlay B télécharge un fichier JSON volumineux (jusqu’à 1,17 Mo pour un site de télécommunications) contenant toutes les définitions de corrections. Sur un site, nous avons constaté qu’il était récupéré à quatre reprises au cours d’une même session de navigation – soit 4,7 Mo de bande passante pour un fichier qui aurait dû être mis en cache. Le fichier JSON contient 11 catégories, mais la grande majorité sont des descriptions d'images générées par l'IA : 4 974 entrées sur 6 975 pour un seul site. Chacune est associée à une URL d'image spécifique : lorsque le CMS renomme un fichier, modifie les dimensions des vignettes ou migre les domaines CDN, les entrées cessent discrètement de correspondre. Les images de remplacement ne reçoivent aucun texte alternatif, ce qui rend la page moins accessible qu'avant l'installation de l'overlay.

Cette superposition déploie également des modules d'exécution qui modifient activement la page : un moteur de correction de 110 Ko, un assistant de menu de navigation de 23 Ko qui restructure la gestion du menu au clavier, un correctif pour le carrousel de 5,8 Ko, ainsi qu'un scanner côté client de 53 Ko utilisant une logique propriétaire plutôt que le moteur axe-core, norme du secteur – ce qui signifie que ses résultats ne peuvent pas être vérifiés de manière indépendante.

La superposition la plus transparente – mais qui comporte tout de même des risques

L'overlay D présentait l'architecture la plus transparente : des fichiers de configuration JSON lisibles par l'utilisateur, avec des commutateurs d'activation/désactivation explicites. Des options telles que addAriaHidden, overwriteAlt, et adjustMetaViewport ont été explicitement définis sur false. Cependant, le moteur sous-jacent (649 Ko) contient 216 setAttribute appels, 47 aria-hidden références, 282 addEventListener inscriptions, et 9 MutationObserver cas. Le moteur prend en charge les modifications radicales du DOM même si la configuration actuelle est prudente : un changement de configuration effectué par le fournisseur pourrait activer des fonctionnalités risquées à l'insu de l'administrateur du site.

Nous avons trouvé des sélecteurs par site contenant des suffixes de hachage générés par JavaScript, tels que button.topHeader__infoButton.js-exclusions85ada2b86bb632424e3ad77c14 qui changent à chaque nouvelle version, et les sélecteurs d'URL des réseaux sociaux qui deviennent obsolètes lorsque le site met à jour ses liens Facebook ou Instagram.

La loi européenne sur l'accessibilité : pourquoi les superpositions ne répondent pas aux exigences de l'EAA

À compter du 28 juin 2025, la loi européenne sur l'accessibilité (EAA) exigera que les produits et services numériques commercialisés dans l'UE respectent des normes d'accessibilité conformes à la norme EN 301 549, qui fait référence aux WCAG 2.1 AA. Contrairement à l'ADA – dont l'application repose principalement sur des poursuites judiciaires privées –, l'EAA est appliquée par les autorités nationales de surveillance du marché, qui ont le pouvoir d'infliger des amendes, d'ordonner des mesures correctives et de retirer du marché les produits non conformes.

Le rejet officiel par l'Allemagne des outils de superposition

L'Allemagne a adopté la position réglementaire la plus claire de tous les pays en matière d'extensions d'accessibilité. Le BFIT-Bund (Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik) – l'organisme fédéral allemand chargé de veiller à l'accessibilité des technologies de l'information – ainsi que tous les organismes de contrôle au niveau des Länder, ont publié une évaluation commune rejetant explicitement les outils d'extension pour la mise en conformité en matière d'accessibilité :

Le 12 mars 2025, le Comité pour les technologies de l'information accessibles (Ausschuss für barrierefreie Informationstechnik, institué en vertu de l'article 5 du BITV 2.0) a réaffirmé cette position lors de sa réunion, exprimant son inquiétude face au fait que les organismes publics continuent de tenter de satisfaire à leurs obligations en matière d'accessibilité en intégrant des outils de superposition. Le comité a conclu qu'« une mise en forme temporairement accessible d'un site web par un logiciel – éventuellement seulement après que l'utilisateur a configuré les paramètres – pour la durée de sa visite ne satisfait pas aux exigences des dispositions légales applicables ».

Le comité a expressément averti que les organismes publics qui utilisent des outils de superposition risquent de rendre leurs sites web moins accessibles, et non l'inverse, ce qui entraîne une détérioration de l'accessibilité (« Verschlechterung der Barrierefreiheit »). Cela correspond parfaitement à notre constat technique selon lequel 26 % des règles de correction par superposition introduisent de nouvelles violations des WCAG.

Label de certification BIK : refusé pour les sites web utilisant des superpositions

Le réseau de certification BIK en Allemagne – qui regroupe les organismes accrédités chargés d’évaluer la conformité des sites web aux normes BITV 2.0, EN 301 549 et WCAG 2.1 AA – a pris une mesure concrète : les sites web utilisant des outils de superposition ne peuvent plus obtenir le label de certification BIK. Les organismes de test ont déclaré qu'ils ne pouvaient pas effectuer d'évaluation de conformité fiable en présence d'un overlay, car celui-ci modifie le DOM lors de l'exécution d'une manière qui rend les résultats des tests peu fiables. Le label BIK est largement utilisé en Allemagne comme preuve de conformité à la norme BITV 2.0 – et il n'est désormais plus accessible aux sites web utilisant un overlay.

Il ne s'agit pas là d'une simple question théorique. Cela signifie qu'un site de commerce électronique allemand utilisant l'une des quatre superpositions que nous avons testées ne peut pas obtenir la certification de conformité standard requise sur le marché allemand.

Confirmation au niveau européen

Cette position réglementaire dépasse le cadre de l'Allemagne. Le Forum européen des personnes handicapées et l'Association internationale des professionnels de l'accessibilité ont publié en 2023 une déclaration commune dans laquelle ils avertissent que les superpositions d'accessibilité ne rendent pas les sites web accessibles ni conformes à la législation européenne en matière d'accessibilité, notamment à l'Acte européen sur l'accessibilité. La Commission européenne s'est également prononcée sur les allégations de conformité relatives aux superpositions, concluant que celles-ci ne peuvent garantir la conformité aux normes applicables.

En vertu de la loi allemande BFSG (Barrierefreiheitsstärkungsgesetz – transposition allemande de l'EAA, en vigueur depuis le 28 juin 2025), les autorités de surveillance du marché peuvent infliger des amendes comprises entre 10 000 et 100 000 euros par infraction. L'évaluation du BFIT-Bund et le refus du réseau de test BIK de certifier les sites utilisant des overlays signifient concrètement que les outils d'overlay n'offrent aucune protection réglementaire en Allemagne – et peuvent même accroître le risque de poursuites.

Sécurité et risques liés à la chaîne d'approvisionnement

Chaque outil de superposition fonctionne en injectant du code JavaScript tiers dans l'espace de noms global de vos pages de production. Ce code JavaScript s'exécute avec les mêmes privilèges que votre propre code : il peut lire et modifier n'importe quel élément DOM, intercepter les soumissions de formulaires, accéder aux cookies, rediriger les utilisateurs et exfiltrer des données. Les implications de cette configuration en matière de sécurité sont considérables et souvent négligées.

La surface d'attaque

Prenons l'exemple de la chaîne logistique : lorsque vous intégrez une couche d'accessibilité à votre site, vous accordez à un fournisseur tiers un accès en écriture continu et illimité à votre DOM de production en ligne. Le CDN du fournisseur héberge le JavaScript, son équipe assure la maintenance du code et son pipeline de déploiement envoie les mises à jour directement sur votre site – sans que vous n'ayez à procéder à une révision du code, sans passer par votre processus d'assurance qualité et sans votre accord.

Si le CDN du fournisseur de la solution de superposition est compromis, l'attaquant est en mesure d'injecter du code malveillant dans tous les sites utilisant cette solution. Si un employé du fournisseur déploie une mise à jour défectueuse, tous les sites des clients sont affectés simultanément. Si le point de terminaison de l'API du fournisseur est détourné, le fichier JSON de correction ou les données de configuration fournis à votre site peuvent être manipulés afin de modifier des champs de formulaire, de rediriger des liens ou d'injecter du contenu de hameçonnage.

L'ampleur de ce risque est directement proportionnelle à l'empreinte DOM de la superposition :

L'Overlay B présente la plus grande surface d'exposition aux risques de la chaîne logistique : 228 appels API par session répartis sur 3 domaines externes, avec une charge utile JSON de 1,17 Mo qui définit la manière dont le DOM doit être modifié. Une réponse API compromise pourrait ordonner au moteur de correction d'injecter du contenu arbitraire dans n'importe quel élément de la page. Le bundle monolithique de 1 285 Ko de la superposition C constitue la plus grande charge utile JavaScript unique – et comme il est minifié et obfusqué, ni l'opérateur du site ni un auditeur de sécurité ne peuvent examiner de manière significative ce qu'il exécute lors de l'exécution.

Conformité à la norme PCI DSS : un conflit direct

Pour tout site de commerce électronique traitant des paiements par carte bancaire, la conformité à la norme PCI DSS n'est pas facultative. Or, nos conclusions révèlent un conflit direct entre l'architecture des outils d'accessibilité par superposition et les exigences de la norme PCI DSS.

L'exigence 6.4.3 de la norme PCI DSS (introduite dans la version 4.0 de la norme PCI DSS, obligatoire à compter du 31 mars 2025) stipule que tous les scripts des pages de paiement qui se chargent et s'exécutent dans le navigateur du consommateur doivent être gérés comme suit : une méthode doit être mise en place pour vérifier que chaque script est autorisé, l'intégrité de chaque script doit être garantie, et un inventaire de tous les scripts doit être tenu à jour, accompagné d'une justification écrite expliquant pourquoi chacun d'entre eux est nécessaire.

Notre analyse a confirmé que les règles de correction des superpositions ciblent activement les éléments DOM des pages de paiement sur plusieurs sites :

Il ne s'agit pas d'un risque théorique : ce sont là des règles de correction réelles que nous avons extraites de sites de production et qui modifient activement les champs de numéro de carte de crédit, les sélecteurs d'adresse de facturation, les boutons des prestataires de paiement et les conteneurs des formulaires de paiement. Conformément à la norme PCI DSS 6.4.3, chacun de ces scripts tiers doit faire l'objet d'une autorisation documentée, d'une vérification d'intégrité et d'une justification écrite.

Réfléchissez à ce que le script d'un fournisseur de superposition peut faire sur votre page de paiement :

L'outil de surveillance, en revanche, ne dispose d'aucune capacité d'écriture dans le DOM. Son script de 4,2 Ko ne peut ni modifier les champs de formulaire, ni intercepter les événements de saisie, ni accéder aux éléments du processus de paiement ni les modifier. Même si le CDN du fournisseur de l'outil de surveillance venait à être compromis, l'attaquant n'aurait accès qu'à un script capable uniquement de lire l'URL de la page et le type d'appareil, et non à un script capable de réécrire le formulaire de paiement. Aux fins de la portée de la norme PCI DSS, l'outil de surveillance ne crée aucune surface de risque supplémentaire sur les pages de paiement.

La question de la discrimination

C'est là le problème de discrimination qui est au cœur de toute interface d'accessibilité : le constat le plus préoccupant n'est pas un défaut technique, mais une pratique consistant à priver systématiquement les utilisateurs en situation de handicap de l'accès à des fonctionnalités que les utilisateurs voyants considèrent comme acquises.

Lorsqu'une superposition masque un bouton Amazon Pay dans l'arborescence d'accessibilité, un utilisateur non voyant dispose de moins d'options de paiement qu'un utilisateur voyant. Lorsqu'un champ de saisie de la quantité dans le panier est masqué, un utilisateur non voyant ne peut pas modifier sa commande. Lorsque les liens vers les résultats de recherche sont masqués, la découverte des produits s'en trouve entravée. Lorsque les notes par étoiles sont masquées, un utilisateur non voyant ne peut pas évaluer la qualité d'un produit comme le ferait un utilisateur voyant.

Il ne s'agit pas là de cas marginaux : ce sont les processus clés du commerce électronique qui sont perturbés par les outils mêmes censés les rendre accessibles.

La communauté des personnes en situation de handicap dénonce cette pratique depuis des années. La fiche d'information sur les superpositions (Overlay Fact Sheet) – signée par des centaines de professionnels de l'accessibilité – met en garde contre le fait que les superpositions d'accessibilité « ne corrigent pas le code HTML sous-jacent » et « constituent souvent un obstacle réel pour les personnes en situation de handicap ». Notre analyse technique en apporte la preuve : 141 éléments fonctionnels masqués aux lecteurs d'écran, 7 balises sans signification ajoutées et 5 066 descriptions générées par IA non vérifiées déployées en production – sur seulement 14 sites.

Pour les exploitants de sites, la question n'est pas de savoir si les superpositions sont « suffisantes », mais plutôt si le déploiement d'un outil qui crée une expérience à deux vitesses peut se justifier : une version pour les utilisateurs voyants, qui bénéficient de toutes les fonctionnalités, et une version filtrée, incomplète, voire parfois absurde, pour les utilisateurs en situation de handicap.

Conséquences sur la conformité à l'ADA : ces corrections sont-elles réellement efficaces ?

La promesse fondamentale de toute solution de superposition est d'améliorer la conformité aux normes ADA en corrigeant les non-conformités aux WCAG lors de l'exécution. Or, notre analyse met en évidence un paradoxe inquiétant : un pourcentage non négligeable de ces solutions introduisent activement de nouvelles non-conformités aux WCAG alors qu'elles tentent d'en corriger les existantes.

Nous avons mis en correspondance chaque règle de correction relevée dans Overlay A avec le critère de conformité WCAG 2.1 spécifique auquel elle se rapporte. Sur les 776 règles pouvant faire l'objet d'une telle mise en correspondance, les résultats se répartissent en deux catégories : les corrections qui résolvent véritablement un problème lié aux WCAG, et celles qui, ce faisant, créent une nouvelle violation des WCAG.

Pour être honnête, les trois quarts des corrections répertoriées constituent de véritables améliorations : ajout de libellés de boutons manquants, correction des hiérarchies de titres, rectification des attributs de saisie semi-automatique et mise en place de mécanismes de verrouillage du focus dans les fenêtres modales. Mais le quart restant est carrément préjudiciable, et ce préjudice touche de manière disproportionnée les utilisateurs mêmes que l'outil prétend aider.

En quoi chaque modèle à risque enfreint les WCAG

Le problème n'est pas seulement que ces corrections échouent, mais aussi qu'elles entraînent des violations de critères de conformité spécifiques des WCAG qui n'existaient pas avant l'application de la superposition. Dans le cadre d'un procès au titre de l'ADA, l'expert du plaignant peut invoquer ces violations causées par la superposition comme preuve que le site fait preuve de discrimination à l'égard des personnes handicapées.

Superposition B : texte alternatif généré par l'IA et WCAG 1.1.1

La norme WCAG 1.1.1 exige que tout contenu non textuel soit accompagné d’une « alternative textuelle qui remplisse la même fonction ». Un texte alternatif généré par l'IA qui décrit le logo d'une entreprise comme « un signe bleu et jaune » ne remplit pas la même fonction : le but d'un logo est l'identification de la marque, et non la description des couleurs. Un texte alternatif tel que « texte » pour une bannière promotionnelle, ou « ville » pour une image principale, ne répond pas non plus à ce critère, mais d'une autre manière : il est tellement vague qu'il en devient inutile.

Sur les 5 068 textes alternatifs générés par IA que nous avons recueillis dans Overlay B, 241 comptaient moins de 15 caractères (trop vagues pour être utiles), 323 dépassaient 125 caractères (ce qui va à l'encontre des bonnes pratiques en matière d'accessibilité pour les lecteurs d'écran) et 156 commençaient par « image de » ou « photo de » (ce qui est redondant, car les lecteurs d'écran annoncent déjà le type d'élément). Seuls 2 avaient été approuvés par un réviseur humain.

Selon les normes applicables aux litiges relevant de l'ADA, l'expert en accessibilité du plaignant signalerait ces éléments comme des manquements à la norme WCAG 1.1.1 – le critère le plus fréquemment invoqué dans les procès relatifs à l'accessibilité du Web au titre de l'ADA. La superposition ne résout pas le problème ; elle remplace simplement une forme de non-conformité (absence de texte alternatif) par une autre (texte alternatif inexact ou vague), tout en donnant au gestionnaire du site une fausse impression de conformité.

Superposition B : Injection d'étiquettes de formulaire à l'exécution – quand « corriger » ne fait qu'empirer les choses

Beyond the consolidated JSON, Overlay B runs a 110 KB remediation engine (remediation-tool.js) that performs 24 distinct DOM mutation rules at runtime on every page load. One of these rules – the EmptyControls handler – targets unlabeled form fields and attempts to inject accessible names by finding nearby <label> elements.

The mechanism works as follows: for each form control without an accessible name, the engine calls a label-finder function that searches for <label for=”id”> elements matching the input’s ID. If found, it injects the label’s text content as an aria-label:

We verified this behavior on a live site – a web agency’s contact page with six form fields. The original HTML had visible labels (“First Name”, “Company Name”, “Last Name”, “Work Email”, “Phone Number”, “Message”) but they were not programmatically associated with their inputs via <label for> or aria-label. Without the overlay, a screen reader would announce each field with no name at all.

Une fois le moteur de correction d'Overlay B activé, un lecteur d'écran a annoncé :

We verified this by examining the saved HTML source with the overlay’s modifications baked in. Every modified element carries a vendor-specific data-*-form=”fx” attribute – the overlay’s own marker confirming it injected the aria-label. The original HTML has <label> elements with correct text (“First Name”, “Last Name”, “Work Email”, etc.) but they have no for attribute and the inputs are not nested inside the labels – so there is no programmatic association. The overlay’s label-finder function only looks for label[for=id], and since the inputs have no id attribute at all, it returns null for every field. The engine then falls back to constructing labels from the name attribute (“first-name” → “Name”, “last-name” → “Name”), input validation type (“email” → “Please enter email address”), or the raw element type (“text” → “Text field”, “select” → “Single select”, “textarea” → “Text area”).

Le résultat est pire que le formulaire d'origine dépourvu d'étiquettes. Avant l'application de la superposition, un utilisateur de lecteur d'écran se trouvait face à sept champs sans étiquette – ce qui prêtait à confusion, mais au moins de manière cohérente. Il pouvait alors s'appuyer sur l'ordre de tabulation et le contexte pour deviner à quel champ correspondait chaque élément. Après l'intervention de la superposition, l'utilisateur se retrouve face à deux champs portant la même étiquette (« Nom » pour le prénom et le nom de famille), deux champs avec des étiquettes de validation inventées qui ne correspondent pas au texte visible, et trois champs avec des noms basés sur le type de données et dénués de sens. L'étiquetage partiel et incorrect est plus déroutant que l'absence totale d'étiquetage, car il donne la fausse impression que le formulaire a été rendu accessible alors que des champs essentiels restent sans étiquette ou mal étiquetés.

Ce constat met également en évidence une lacune dans le fichier JSON de correction d'Overlay B. Le fichier JSON contenait 87 entrées de texte alternatif générées par l'IA et aucune entrée de correction de formulaire pour ce site. L'injection de libellés de formulaire se produit entièrement lors de l'exécution via le gestionnaire de règles EmptyControls : elle n'apparaît pas dans le fichier JSON de correction consolidé, n'est suivie dans aucun tableau de bord que l'exploitant du site peut consulter et n'est pas soumise à une validation humaine. L'exploitant du site n'a aucun moyen de savoir que son formulaire de contact est mal libellé, à moins de le tester lui-même à l'aide d'un lecteur d'écran.

The remediation engine’s 24 rule handlers collectively perform: aria-label injection on form fields, links, images, and dialogs; aria-hidden toggling; role modification (heading, presentation, menuitem, button, img); tabindex injection to make non-interactive elements focusable; alt text from the AI JSON; style overrides to make hidden elements visible; aria-required injection; aria-describedby associations between fields and error messages; heading text rewrites; broken link URL corrections; <meta viewport> modification; and <html lang> changes. All of this executes at runtime in the visitor’s browser on every page load – none of it is visible in the consolidated remediation JSON.

L'impact net de la mise en conformité avec l'ADA

Le problème fondamental réside dans le fait que les outils de superposition confondent couverture et conformité. Une superposition peut renvoyer à 1 058 règles de correction et prétendre répondre à plus de 40 critères de succès des WCAG. Mais lorsque 26 % de ces corrections introduisent de nouvelles violations – notamment des non-conformités de niveau A dues à la dissimulation d'éléments fonctionnels –, le niveau de conformité global peut s'avérer pire que celui du site non modifié.

Un site sans superposition comportant 50 non-conformités aux WCAG se trouve dans une situation juridique plus claire qu'un site avec superposition comportant 30 non-conformités initiales et 203 non-conformités induites par la superposition – car ces dernières démontrent que l'exploitant du site a déployé un outil qui discrimine activement les utilisateurs handicapés, ce qui compromet toute défense fondée sur la bonne foi.

En résumé