Description de l'image : Panneau « Fiche d'information sur les superpositions » encadré d'un ruban de signalisation, indiquant des avertissements concernant les outils de superposition pour l'accessibilité.
Fiche d'information sur les superpositions, vérifiée : nos données techniques à l'appui de chaque affirmation
Fiche d'information sur les superpositions, vérifiée : nos données techniques à l'appui de chaque affirmation
La communauté spécialisée dans l'accessibilité met en garde contre les outils de superposition depuis des années. Nous avons intercepté le trafic de production provenant de quatre superpositions et avons mis en correspondance nos conclusions avec chacune des affirmations figurant dans la fiche d'information sur les superpositions, fournissant ainsi les preuves techniques qui sous-tendent chaque mise en garde.
Qu'est-ce que la fiche d'information sur la superposition ?
La fiche d'information « Overlay » est une déclaration émanant de la communauté et signée par plus de 600 professionnels de l'accessibilité, parmi lesquels figurent des contributeurs et des rédacteurs des spécifications WCAG, ARIA et HTML, ainsi que des experts internes en accessibilité issus d'entreprises telles que Google, Microsoft, Apple, Shopify, eBay et Target. Elle formule plusieurs affirmations précises concernant les limites et les risques liés aux outils de superposition d'accessibilité.
Notre étude – qui porte sur 924 requêtes HTTP interceptées, avec 579 corps de réponse complets provenant de 14 sites de commerce électronique en ligne, ainsi que des instantanés DOM enregistrés intégrant les modifications de superposition – constitue la première base de données techniques à grande échelle permettant de vérifier chaque affirmation à l'aide de données de production réelles. Voici ce que nous avons découvert.
Affirmation n° 1 : « Les overlays ne corrigent pas le code sous-jacent »
La fiche d'information sur les superpositions indique que celles-ci permettent d'apporter des « modifications temporaires à l'interface utilisateur » plutôt que de modifier de manière permanente le code source.
Toutes les superpositions que nous avons analysées fonctionnent exclusivement au niveau du DOM : elles modifient les éléments une fois la page chargée, sans modifier le code HTML sous-jacent. Nous avons vérifié cela à l'aide de quatre mécanismes distincts :
Superposition A charge des fichiers de correction JavaScript spécifiques à chaque site, au nombre de 1 023 defineFix règles qui utilisent setAttribute, attr(), et hideFromAT() pour modifier des éléments DOM à l'exécution. Si le script de superposition est supprimé ou ne parvient pas à se charger, toutes les corrections disparaissent instantanément – le code sous-jacent reste inchangé.
Overlay B télécharge un fichier JSON de correction de 1,17 Mo et applique les corrections via un moteur de correction distinct. Les corrections sont associées à des URL d'images spécifiques : lorsque la superposition est supprimée, les 5 068 entrées de texte alternatif disparaissent. Les images se retrouvent alors sans aucun texte alternatif.
Superposition C fournit un ensemble monolithique de 794 Ko qui modifie le DOM via 227 setAttribute appels, 82 modifications de rôle et 128 aria-label injections. Aucune d'entre elles ne modifie le code HTML côté serveur.
Superposition D applique des noms accessibles définis par configuration via un moteur de 649 Ko avec 216 setAttribute appels. Ces corrections ne sont effectives que tant que le moteur est en marche.
L'outil de surveillance, en revanche, ne corrige rien : il signale simplement les problèmes à un tableau de bord destiné aux développeurs. Ce sont les développeurs qui les corrigent dans le code source, où les corrections sont définitives, testées et déployées via les pipelines CI/CD habituels.
Que se passe-t-il en cas de panne du CDN de superposition ?
La fiche d'information laisse entendre que les corrections par superposition sont temporaires. Nous pouvons quantifier précisément ce caractère temporaire : si le CDN qui héberge le code JavaScript de la superposition tombe en panne, toutes les corrections disparaissent instantanément. Nos données mettent en évidence la chaîne de dépendances :
Superposition A : Par site active.js (jusqu'à 238 Ko) sont chargés à partir d'un seul CDN. Si ce CDN est inaccessible, ne serait-ce que pendant 30 secondes, aucune correction d'accessibilité n'est appliquée aux pages chargées pendant cette période. Les 1 023 règles de correction, les 35 pièges de focus modaux et toutes les balises ARIA injectées disparaissent tout simplement.
Superposition B : Le moteur de correction dépend de trois domaines externes : un CDN pour les scripts, une API pour les réglages et les configurations, et un CDN distinct pour l'API de texte alternatif généré par IA. Si l'un de ces trois éléments tombe en panne, différentes parties du pipeline de correction cessent de fonctionner, ce qui peut laisser le DOM dans un état partiellement modifié où certaines corrections ont été appliquées, mais pas d'autres.
Overlay C : L'ensemble de l'overlay est constitué d'un seul paquet de 794 Ko provenant d'un seul domaine. Une panne du CDN entraîne la disparition totale du widget. Cependant, comme le MutationObserver de l'overlay surveillait le DOM et modifiait des éléments, un chargement partiel de la page — au cours duquel l'observateur a été initialisé mais où la logique de correction n'a pas été menée à bien — pourrait laisser le DOM dans un état incohérent.
L'outil de surveillance ne dépend en rien d'un CDN pour son accessibilité. Si son CDN tombe en panne, la seule conséquence est que les statistiques relatives aux visites de pages cessent d'être enregistrées. L'accessibilité du site n'est pas affectée, car toutes les corrections sont intégrées au code source ; elles ne dépendent pas du chargement de scripts tiers.
Affirmation n° 2 : « Une superposition ne permet pas d'assurer une conformité totale »
La fiche d'information précise que « l'incapacité avérée de ces produits à résoudre tous les problèmes possibles signifie qu'ils ne permettent pas de mettre un site web en conformité ».
Nous avons mis en correspondance 776 règles de correction de l'Overlay A avec des critères de conformité spécifiques des WCAG. 26 % (203 règles) introduisent de nouvelles violations des WCAG tout en cherchant à corriger celles qui existent déjà, notamment hideFromAT() appels qui provoquent cinq défaillances de niveau A simultanées par instance.
Les manquements spécifiques à la conformité que nous avons constatés :
WCAG 1.1.1 (Contenu non textuel) : Overlay B génère des textes alternatifs générés par IA qui ne satisfont pas au critère de « finalité équivalente » : un logo d'entreprise décrit comme « un signe bleu et jaune », une icône de navigation décrite comme « un simple rectangle noir ». 241 entrées comptaient moins de 15 caractères. 323 dépassaient 125 caractères.
WCAG 2.1.1 (Clavier) : La superposition A masque les éléments interactifs dans l'arborescence d'accessibilité, les rendant inaccessibles au clavier. Les boutons de paiement, les commandes du panier et les liens vers les résultats de recherche masqués par hideFromAT() ne peut pas recevoir le focus ni être commandé à l'aide du clavier.
WCAG 4.1.2 (Nom, rôle, valeur) : Superposition A injecte aria-label="true" sur 7 éléments répartis sur 3 sites – un bug de code où le nom accessible est la chaîne de caractères dénuée de sens « true ». La superposition A s'applique également role="presentation" jusqu'à 115 éléments, en supprimant toute signification sémantique des tableaux, des titres et des repères.
WCAG 1.3.1 (Informations et relations) : Quand role="presentation" Lorsqu'un élément est appliqué à un tableau de données, les lecteurs d'écran ne peuvent plus naviguer par lignes et par colonnes. La structure du tableau disparaît de l'arborescence d'accessibilité.
Nous avons mis en correspondance 776 règles de correction de l'Overlay A avec des critères de succès spécifiques des WCAG. Cette analyse met en évidence le paradoxe de la conformité de l'Overlay :
| Critère WCAG | Nombre total de corrections | Authentique | Nocif | Effet net |
|---|---|---|---|---|
| 4.1.2 Nom, rôle, valeur | 292 | 260 | 32 | En résumé : les bogues compromettent les corrections effectives |
| 2.4.4 Objectif du lien | 158 | 108 | 50 | 45 liens cachés = objectif manqué |
| 1.1.1 Contenu non textuel | 108 | 28 | 80 | Bilan négatif – plus de mal que de bien |
| 1.3.1 Informations et relations | 109 | 92 | 17 | Plutôt utile, mais la suppression des rôles nuit à la structure |
| 2.1.1 Clavier | 36 | 22 | 14 | Les éléments masqués ne sont plus accessibles au clavier |
| Autres (6 critères) | 73 | 69 | 4 | Globalement positif |
| Total | 776 | 579 (75 %) | 197 (25 %) |
La rubrique la plus préoccupante est celle des WCAG 1.1.1 (Contenu non textuel) : sur les 108 règles de correction visant ce critère, 80 sont nocifs – Masquer complètement les 52 images d'AT via hideFromAT(), et 28 marquent les images de contenu comme décoratives via alt="". La superposition rend le contenu non textuel moins accessible, sans plus. C'est exactement le contraire de ce qu'exige la norme WCAG 1.1.1.
La Commission fédérale du commerce des États-Unis a confirmé cette conclusion lorsqu'elle a infligé une amende d'un million de dollars à un fournisseur d'outils d'accessibilité en avril 2025, affirmant que cet outil « ne parvenait pas ou n'avait pas réussi à rendre conformes aux WCAG des éléments de base et essentiels des sites web, tels que les menus, les titres, les tableaux, les images, les enregistrements et bien d'autres encore ».
Affirmation n° 3 : « Les superpositions peuvent créer de nouveaux obstacles à l'accessibilité »
La fiche d'information met en garde contre le fait que les produits de superposition peuvent « constituer un obstacle réel pour les personnes handicapées ».
Nous avons recensé 141 éléments masqués aux lecteurs d'écran via hideFromAT(), 115 rôles sémantiques extraits via role="presentation", 63 images discrètement qualifiées de décoratives via alt="", et 7 éléments dénués de sens aria-label="true".
Les exemples les plus préjudiciables se produisent lors des processus de paiement et de mise au panier :
Sur le site d'un détaillant de luxe, les boutons Amazon Pay, Shop Pay et Klarna sont masqués aux technologies d'assistance. Lors du paiement, un utilisateur aveugle voit moins d'options de paiement qu'un utilisateur voyant. Sur le site d'un détaillant de mode, les champs de saisie de la quantité dans le panier et les boutons de mise à jour sont masqués : un utilisateur aveugle ne peut donc pas modifier sa commande.
Les liens vers les résultats de recherche de produits sont masqués sur deux sites, ce qui empêche les utilisateurs non-voyants de découvrir les produits. Les notes par étoiles sont masquées : les utilisateurs non-voyants ne peuvent donc pas évaluer la qualité des produits de la même manière que les utilisateurs voyants.
L'organisme fédéral allemand de surveillance (BFIT-Bund) a confirmé cette tendance dans son évaluation conjointe officielle : « Il arrive fréquemment que l'utilisation de tels outils crée des obstacles supplémentaires sur le site web qui n'auraient pas existé sans cet outil. »
Affirmation n° 4 : « Les utilisateurs disposeront déjà des outils dont ils ont besoin »
La fiche d'information fait valoir que « les utilisateurs finaux auxquels ces fonctionnalités sont censées s'adresser disposeront déjà des fonctionnalités nécessaires sur leur ordinateur ».
L'overlay C associe un MutationObserver à l'ensemble du document et intercepte 47 événements clavier. Cela entraîne des conflits directs avec les lecteurs d'écran, les outils de navigation au clavier et les extensions de navigateur dont dépendent déjà les utilisateurs en situation de handicap.
Lorsqu'un utilisateur de lecteur d'écran a configuré ses raccourcis clavier et ses préférences de navigation, une superposition qui intercepte keydown, keyup, et keypress certains événements peuvent passer outre ces préférences. Les 47 références d'événements clavier d'Overlay C, contenues dans son paquet de 794 Ko, constituent une surface d'interception clavier considérable. Le moteur d'Overlay D contient 282 addEventListener enregistrements – dont chacun pourrait entrer en conflit avec les gestionnaires d'événements des technologies d'assistance.
Affirmation n° 5 : « La valeur pratique des widgets superposés est largement surestimée »
La fiche d'information indique que les fonctionnalités des widgets, telles que les commandes de contraste et de taille du texte, n'apportent qu'une valeur ajoutée limitée, car les utilisateurs disposent déjà d'équivalents au niveau du système.
Les superpositions que nous avons analysées imposent un temps de réseau cumulé de 4 à 84 secondes par session, téléchargent entre 500 Ko et 2,9 Mo de code JavaScript par page et, dans un cas précis, déclenchent 83 requêtes CORS de pré-vérification qui représentent 38,8 secondes de perte de temps purement liée au protocole – tout cela pour offrir des fonctionnalités que les systèmes d'exploitation, les navigateurs et les technologies d'assistance fournissent déjà de manière native.
La pire page unique de l'overlay B a généré 48 requêtes, ce qui a pris 12,8 secondes de temps de réseau. À titre de comparaison, le seuil défini par les Core Web Vitals de Google pour un Largest Contentful Paint « médiocre » est de 2,5 secondes. À lui seul, l'overlay a dépassé ce seuil de cinq fois.
Overlay A a consacré 75 % de ses 33,9 secondes de temps réseau à l'analyse comportementale – soit 58 requêtes POST de suivi vers son propre point de terminaison. Les requêtes CDN liées à l'accessibilité n'ont représenté que 25 % du temps total. La majeure partie de l'impact sur les performances est due à la collecte de données par le fournisseur, et non à l'amélioration de l'accessibilité.
Affirmation n° 6 : « Les propriétaires de sites devraient adopter des stratégies plus solides, indépendantes et durables »
La fiche d'information préconise « la suppression des superpositions d'accessibilité Web » au profit de stratégies d'accessibilité permanentes.
L'outil de surveillance utilisé dans notre étude incarne précisément cette approche : analyse avec axe-core, signalement des problèmes à l'aide d'identifiants de règles standardisés et de niveaux de gravité, puis correction par les développeurs directement dans le code source. Aucune modification du DOM, aucun suivi des utilisateurs, aucun risque de panne du site, aucun conflit avec la norme PCI DSS. Les résultats d'analyse que nous avons recueillis ont montré des scores allant de 53,1 à 100, accompagnés de détails spécifiques sur les violations (contraste des couleurs, ordre des titres, étiquettes, repères uniques) sur lesquels les développeurs peuvent agir immédiatement.
La différence fondamentale que révèlent nos données est d'ordre architectural : les superpositions gèrent un ensemble parallèle de définitions de corrections qui reflètent la structure DOM du site et deviennent obsolètes à chaque déploiement. Un outil de surveillance analyse le DOM tel qu'il se présente au moment de l'analyse, signale ce qu'il détecte, puis repart de zéro lors de l'analyse suivante. Il n'y a pas d'accumulation de dette technique, 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é.
Au-delà de la fiche d'information : ce qu'apportent nos données
Nos recherches ont mis en lumière des résultats qui dépassent le cadre de la fiche d'information sur les superpositions :
Conflit avec la norme PCI DSS 4.0 : Les règles de correction par superposition ciblent spécifiquement les éléments de la page de paiement – nous avons répertorié les sélecteurs pour #cardNumber, #billingState, les boutons de paiement et les formulaires de paiement. Conformément à l'exigence 6.4.3 de la norme PCI DSS (obligatoire depuis mars 2025), chaque script de page de paiement doit faire l'objet d'une autorisation documentée et d'une vérification d'intégrité. Les superpositions ne satisfont pas à cette exigence. Au sein d'un groupe spécialisé dans les produits de luxe, des sélecteurs ciblant les pages de paiement identiques sont partagés entre deux sites de marques (96 % de chevauchement du code), ce qui double l'ampleur des répercussions en cas de compromission de la chaîne d'approvisionnement.
Taux d'échantillonnage aussi bas que 1,7 % : Nous avons découvert que les données POST d'analyse d'une superposition contiennent un samplingRate Ce champ indique que seules 1,7 à 4,5 % des sessions déclenchent une analyse de conformité. Les 95 à 98 % restants bénéficient de corrections DOM sans aucune vérification.
Violations du RGPD : trois fenêtres superposées transmettent les identifiants des utilisateurs, les données d'empreinte numérique des appareils et les analyses comportementales avant même que tout mécanisme de consentement ne puisse s'activer – ce qui constitue une non-conformité automatique au regard de l'arrêt Planet49 de la CJUE. Une de ces fenêtres superposées transmet un UUID persistant, identique à chaque chargement de page, permettant ainsi d'établir des profils de navigation complets sur l'ensemble des pages.
Rejet par les autorités de régulation allemandes : le BFIT-Bund (l'organisme fédéral de surveillance allemand) a officiellement rejeté les superpositions dans le cadre des tests de conformité, et les organismes de certification BIK refusent de délivrer des labels de conformité aux sites web qui utilisent des superpositions. En vertu de la loi allemande BFSG (transposition de la directive EAA), les amendes vont de 10 000 à 100 000 euros par infraction.
Injection d'étiquettes dans les formulaires à l'exécution qui détériore leur fonctionnement : Le moteur de correction d'une superposition (110 Ko) applique 24 règles de modification du DOM lors de l'exécution, notamment un gestionnaire EmptyControls qui tente d'étiqueter les champs de formulaire non étiquetés. Sur un formulaire de contact en ligne comportant sept champs, le moteur a injecté aria-label valeurs extraites du code HTML name attribut plutôt que les libellés visibles – ce qui fait que deux champs partagent le même libellé « Nom » (provenant de name="first-name" et name="last-name"), trois champs libellés avec des types d'éléments génériques (« Champ de texte », « Sélection unique », « Zone de texte ») et deux utilisant des descriptions de type validation à la place de l'étiquette visible réelle. L'instantané DOM enregistré confirme que chaque élément modifié porte le marqueur d'attribut de données spécifique au fournisseur de l'overlay. Le code HTML d'origine comportait des étiquettes visibles correctes (« Prénom », « Nom de l'entreprise », etc.), mais celles-ci ne comportaient pas for attributs – une correction simple dans le code source que le moteur d'exécution de la superposition n'a pas réussi à reproduire correctement.
Correction d'un fichier JSON contaminé par du contenu provenant d'autres domaines : le fichier JSON de correction prédéfini d'une superposition pour un site bancaire contenait 7 entrées de texte alternatif, dont une seule provenait effectivement du domaine de la banque (avec un texte alternatif constitué d'un simple espace). Les 6 entrées restantes décrivaient des images provenant de domaines sans aucun rapport : un outil polonais de test d'accessibilité (icônes de bookmarklet ANDI), une API chinoise de comparaison de prix (icônes de widget de chat), un réseau publicitaire russe de teasers (création publicitaire) et le CDN de navigateur de Xiaomi (interface utilisateur de demande de traduction). Le scanner de l’overlay avait capturé ces éléments lors d’une session précédente au cours de laquelle l’internaute avait activé des extensions de navigateur tierces et des injections publicitaires – et avait stocké de manière permanente les descriptions générées par l’IA dans le fichier de correction de la banque, téléchargé par chaque visiteur sur chaque page. Le fichier JSON est accessible au public sur le CDN de l’overlay sans authentification.
Les mises en garde contenues dans la fiche d'information « Overlay », rédigées par des professionnels de l'accessibilité sur la base de leur expérience, sont désormais étayées par des données de production recueillies sur 14 sites de commerce électronique en activité. Toutes les principales affirmations se vérifient – et la réalité, dans plusieurs domaines, est pire que ce que décrit la fiche d'information.
Affirmation n° 7 : « Les superpositions nuisent aux efforts légitimes en matière d'accessibilité »
La documentation relative aux « fausses allégations sur les superpositions » met en garde contre le fait que les superpositions créent « une fausse impression selon laquelle le problème de l'accessibilité est résolu » et sont « contraires aux principes fondamentaux de l'ADA ».
Un seul overlay ne couvre que 1,7 à 4,5 % des sessions des visiteurs. Les exploitants de sites reçoivent des indicateurs de conformité basés sur cet échantillon restreint, ce qui crée un faux sentiment de conformité alors que 95 à 98 % des sessions ne sont jamais vérifiées. Lorsqu'un déploiement enfreint les règles de correction, le faible taux d'échantillonnage fait que la régression peut passer inaperçue pendant plusieurs jours – période durant laquelle l'exploitant du site pense être en conformité.
Le problème plus profond réside dans le fait que les superpositions font passer le modèle mental de « nous devons créer des produits accessibles » à « nous avons installé un widget qui gère l'accessibilité ». Nos données montrent ce que cela donne concrètement : un détaillant de sacs à main de luxe compte 383 règles de correction dans sa superposition, mais le code HTML sous-jacent présente toujours tous les problèmes d'accessibilité d'origine. Si le CDN du fournisseur de la superposition est hors service pendant 30 minutes, tous les obstacles réapparaissent instantanément. Le site n'a jamais été véritablement corrigé.
Affirmation n° 8 : Préoccupations liées à la vie privée et au suivi
Bien que ce ne soit pas le sujet principal de la fiche d'information sur les superpositions, des défenseurs des personnes handicapées ont soulevé des préoccupations en matière de confidentialité, soulignant que les superpositions permettent de détecter l'utilisation de technologies d'assistance.
Les données que nous avons interceptées révèlent un suivi qui va bien au-delà de la simple détection des AT.
Superposition A : 58 requêtes POST d'analyse par session vers son propre point de terminaison, chacune contenant un identifiant de session (sid), URL de la page complète (pg), identifiant de chargement de la page (plid), la catégorie d'appareil et le type d'événement. 75 % du temps total passé sur le réseau est consacré à ces appels de suivi.
Calque B : Un UUID persistant (uid) envoyé dans chaque requête POST de configuration – un identifiant identique sur toutes les pages de la session, ce qui permet au fournisseur de constituer un profil de navigation complet. L'UUID est le même : nous avons constaté qu'il restait inchangé sur les cinq pages d'un site de télécommunications.
Calque C : USER-BEHAVIOR-ANALYTICS Envoyer des données POST comprenant le domaine, la version du widget et les événements d'interaction. Identification de l'appareil via navigator.userAgent, navigator.userAgentData, et navigator.maxTouchPoints. Trois localStorage clés dont l'état est conservé d'une session à l'autre.
Ces trois éléments déclenchent leur suivi dès le chargement de la page, avant même qu'un mécanisme de consentement puisse s'activer. Conformément à l'arrêt de la CJUE dans l'affaire Planet49, le suivi non essentiel nécessite un consentement préalable. Ces fenêtres contextuelles sont automatiquement non conformes au RGPD sur tous les sites destinés à l'UE.
Affirmation n° 9 : « Les superpositions comportent un risque juridique »
La fiche d'information souligne que les solutions de superposition ne peuvent « éliminer le risque juridique », contrairement à ce qu'affirment les fournisseurs.
En 2024, plus de 1 023 entreprises utilisant des widgets d'accessibilité ont été poursuivies pour violation de l'ADA, soit 25 % de l'ensemble des poursuites judiciaires liées à l'accessibilité numérique cette année-là. Rien qu'en février 2025, 132 entreprises utilisant des superpositions ont été poursuivies en justice. La FTC a infligé une amende d'un million de dollars à un fournisseur. Les organismes de réglementation allemands ont explicitement rejeté les superpositions pour des raisons de conformité. Le risque juridique n'est pas hypothétique : il est documenté, quantifié et en augmentation.
Notre base de données sur les affaires judiciaires (8 541 dossiers relatifs à l'ADA) contient des litiges directs impliquant des fournisseurs de solutions de superposition : trois affaires de brevets/secrets commerciaux entre deux fournisseurs (2020-2022), un recours collectif intenté par un client contre un fournisseur (2024) et une action en justice en cours contre un autre fournisseur, intentée par une petite entreprise qui a été poursuivie bien qu'elle ait utilisé la solution de superposition (2024, requête en irrecevabilité rejetée par le juge en 2026).
Cet outil de surveillance n'a fait l'objet d'aucun litige lié à des problèmes d'accessibilité – une conséquence logique : comme il ne modifie pas le DOM, il ne peut pas créer les obstacles susceptibles de donner lieu à des poursuites judiciaires.
Le manque de données est désormais comblé
Pendant des années, la fiche d'information sur les superpositions et les mises en garde de la communauté de l'accessibilité à ce sujet reposaient sur l'expérience professionnelle, les témoignages d'utilisateurs et des tests manuels. Les détracteurs pouvaient les rejeter en les qualifiant d'anecdotiques ou de partiales. Nos recherches comblent cette lacune en fournissant la première base de données techniques à grande échelle : des données de production interceptées provenant de 924 requêtes réseau, 579 fichiers source extraits sur 14 sites de commerce électronique en ligne au cours de trois sessions de capture indépendantes, complétées par des instantanés DOM enregistrés qui conservent les modifications exactes en temps réel que les superpositions injectent dans les pages de production.
Toutes les affirmations majeures contenues dans la fiche d'information sur les superpositions sont étayées par nos données. Plusieurs d'entre elles sont même en deçà de ce que nous avons constaté. Quant aux aspects que la fiche d'information ne couvre pas – les conflits avec la norme PCI DSS, les taux d'échantillonnage des analyses, le suivi avant consentement dans le cadre du RGPD, le rejet réglementaire en Allemagne –, ils constituent des dimensions de risque supplémentaires que la communauté de l'accessibilité a identifiées par l'expérience, mais qu'elle n'avait pas pu quantifier auparavant.
Les preuves se trouvent dans le code. Le code se trouve dans le trafic intercepté. Ce trafic provient de sites de production desservant de vrais clients. Les résultats parlent d'eux-mêmes.