Bildbeschreibung: Ein mit Absperrband eingerahmtes Schild mit der Aufschrift „Overlay-Infoblatt“, das auf Gefahren im Zusammenhang mit Overlay-Tools für die Barrierefreiheit hinweist.
Das Overlay-Datenblatt, verifiziert: Unsere technischen Belege für jede Behauptung
Das Overlay-Datenblatt, verifiziert: Unsere technischen Belege für jede Behauptung
Die Barrierefreiheits-Community warnt schon seit Jahren vor Overlay-Tools. Wir haben den Produktionsdatenverkehr von vier Overlay-Diensten abgefangen und unsere Ergebnisse den einzelnen Aussagen im „Overlay Fact Sheet“ zugeordnet – und damit die technischen Belege für jede Warnung geliefert.
Was ist das Overlay-Datenblatt?
Das „Overlay Fact Sheet“ ist eine von der Community initiierte Erklärung, die von über 600 Fachleuten für Barrierefreiheit unterzeichnet wurde – darunter Mitwirkende und Redakteure der WCAG-, ARIA- und HTML-Spezifikationen sowie interne Barrierefreiheitsexperten von Unternehmen wie Google, Microsoft, Apple, Shopify, eBay und Target. Darin werden mehrere konkrete Aussagen zu den Einschränkungen und Risiken von Overlay-Tools für Barrierefreiheit getroffen.
Unsere Untersuchung – 924 abgefangene HTTP-Anfragen mit 579 vollständigen Antworttexten auf 14 aktiven E-Commerce-Websites sowie gespeicherte DOM-Momentaufnahmen mit integrierten Overlay-Änderungen – liefert die erste groß angelegte technische Evidenzbasis, um jede Behauptung anhand tatsächlicher Produktionsdaten zu überprüfen. Hier sind unsere Ergebnisse.
Behauptung 1: „Overlays reparieren den zugrunde liegenden Code nicht“
Im Informationsblatt zu Overlays heißt es, dass Overlays „vorübergehende Änderungen an der Benutzeroberfläche“ ermöglichen, anstatt den Quellcode dauerhaft zu ändern.
Jedes von uns analysierte Overlay arbeitet ausschließlich auf der DOM-Ebene – es verändert Elemente nach dem Laden der Seite, ohne den zugrunde liegenden HTML-Quellcode zu ändern. Wir haben dies anhand von vier verschiedenen Mechanismen bestätigt:
Überlagerung A Lädt standortspezifische JavaScript-Korrekturdateien, die 1.023 enthalten defineFix Regeln, die setAttribute, attr()und hideFromAT() um DOM-Elemente zur Laufzeit zu ändern. Wenn das Overlay-Skript entfernt wird oder nicht geladen werden kann, verschwinden alle Korrekturen sofort – der zugrunde liegende Code bleibt unverändert.
Overlay B lädt eine 1,17 MB große JSON-Datei mit Korrekturen herunter und wendet diese über eine separate Korrektur-Engine an. Die Korrekturen sind an bestimmte Bild-URLs gebunden – wenn das Overlay entfernt wird, verschwinden alle 5.068 Alt-Text-Einträge. Die Bilder haben dann wieder überhaupt keinen Alt-Text mehr.
Überlagerung C liefert ein 794 KB großes monolithisches Bundle, das das DOM über 227 setAttribute Aufrufe, 82 Rollenänderungen und 128 aria-label Injektionen. Keine davon greift auf das serverseitige HTML zu.
Überlagerung D wendet konfigurationsgesteuerte, barrierefreie Namen über eine 649-KB-Engine mit 216 setAttribute Aufrufe. Die Korrekturen sind nur so lange wirksam, wie die Engine läuft.
Das Überwachungstool hingegen behebt die Probleme nicht – es meldet sie lediglich an ein Entwickler-Dashboard. Die Entwickler beheben sie im Quellcode, wo die Korrekturen dauerhaft sind, getestet werden und über normale CI/CD-Pipelines bereitgestellt werden.
Was passiert, wenn das Overlay-CDN ausfällt?
Aus dem Fact Sheet geht hervor, dass Overlay-Korrekturen nur vorübergehend sind. Wir können genau beziffern, wie vorübergehend sie sind: Wenn das CDN, das das JavaScript des Overlays bereitstellt, offline geht, verschwinden alle Korrekturen sofort. Unsere Daten zeigen die Abhängigkeitskette:
Einschub A: Pro Standort active.js (bis zu 238 KB) werden von einem einzigen CDN geladen. Ist dieses CDN auch nur für 30 Sekunden nicht erreichbar, erhält kein einziger Seitenladevorgang in diesem Zeitraum Barrierefreiheitskorrekturen. Die 1.023 Korrekturregeln, die 35 modalen Fokusfallen und alle eingefügten ARIA-Labels verschwinden einfach.
Overlay B: Die Korrektur-Engine ist auf drei externe Domänen angewiesen: ein CDN für Skripte, eine API für Optimierungen und Konfigurationen sowie ein separates CDN für die KI-Alt-Text-API. Fällt eine dieser drei Domänen aus, kommt es zu Ausfällen in verschiedenen Teilen der Korrektur-Pipeline – was dazu führen kann, dass das DOM in einem teilweise veränderten Zustand verbleibt, in dem einige Korrekturen angewendet wurden, andere jedoch nicht.
Overlay C: Das gesamte Overlay besteht aus einem einzigen 794-KB-Bundle von einer Domain. Ein Ausfall des CDN führt zum vollständigen Verschwinden des Widgets. Da der MutationObserver des Overlays jedoch das DOM überwachte und Elemente modifizierte, könnte ein teilweiser Seitenladevorgang, bei dem der Observer initialisiert wurde, die Korrekturlogik jedoch nicht abgeschlossen wurde, das DOM in einen inkonsistenten Zustand versetzen.
Das Überwachungstool ist hinsichtlich der Barrierefreiheit vollständig unabhängig vom CDN. Sollte das CDN ausfallen, hat dies lediglich zur Folge, dass die Kennzahlen zu den Seitenaufrufen nicht mehr erfasst werden. Die Barrierefreiheit der Website bleibt davon unberührt, da alle Korrekturen im Quellcode enthalten sind – sie hängen nicht vom Laden von Skripten von Drittanbietern ab.
Behauptung 2: „Eine vollständige Konformität lässt sich mit einem Overlay nicht erreichen“
In dem Informationsblatt heißt es: „Da diese Produkte nachweislich nicht in der Lage sind, alle möglichen Probleme zu beheben, können sie eine Website nicht in Übereinstimmung mit den Vorschriften bringen.“
Wir haben 776 der Korrekturregeln von Overlay A bestimmten WCAG-Erfolgskriterien zugeordnet. 26 % (203 Regeln) führen zu neuen WCAG-Verstößen, während sie versuchen, bestehende zu beheben – darunter hideFromAT() Aufrufe, die pro Instanz fünf gleichzeitige Level-A-Fehler verursachen.
Konkrete Verstöße gegen die Vorschriften, die wir dokumentiert haben:
WCAG 1.1.1 (Nicht-Text-Inhalte): Overlay B generiert AI-Alt-Text, der den Test auf „gleichwertigen Zweck“ nicht besteht – ein Firmenlogo, das als „ein blau-gelbes Zeichen“ beschrieben wird, ein Navigationssymbol, das als „ein einfaches schwarzes Rechteck“ beschrieben wird. 241 Einträge waren kürzer als 15 Zeichen. 323 waren länger als 125 Zeichen.
WCAG 2.1.1 (Tastatur): Das Overlay A blendet interaktive Elemente im Barrierefreiheitsbaum aus, sodass sie über die Tastatur nicht mehr erreichbar sind. Zahlungsschaltflächen, Warenkorb-Steuerelemente und Links zu Suchergebnissen, die durch hideFromAT() kann weder den Fokus erhalten noch über die Tastatur bedient werden.
WCAG 4.1.2 (Name, Funktion, Wert): Overlay A fügt ein aria-label="true" an 7 Elementen an 3 Stellen – ein Programmierfehler, bei dem der barrierefreie Name die bedeutungslose Zeichenfolge „true“ lautet. Overlay A gilt ebenfalls role="presentation" auf 115 Elemente, wobei Tabellen, Überschriften und Orientierungshilfen ihrer semantischen Bedeutung beraubt werden.
WCAG 1.3.1 (Informationen und Zusammenhänge): Wenn role="presentation" Wird auf eine Datentabelle angewendet, können Screenreader nicht mehr zeilen- und spaltenweise navigieren. Die Tabellenstruktur verschwindet aus dem Barrierefreiheitsbaum.
Wir haben 776 der Korrekturregeln von Overlay A bestimmten WCAG-Erfolgskriterien zugeordnet. Die Aufschlüsselung verdeutlicht das Paradoxon der Overlay-Konformität:
| WCAG-Kriterium | Gesamtzahl der Korrekturen | Original | Schädlich | Nettoeffekt |
|---|---|---|---|---|
| 4.1.2 Name, Rolle, Wert | 292 | 260 | 32 | Gemischt – Fehler untergraben echte Korrekturen |
| 2.4.4 Zweck des Links | 158 | 108 | 50 | 45 versteckte Links = Zweck verfehlt |
| 1.1.1 Nicht-Text-Inhalte | 108 | 28 | 80 | Unter dem Strich negativ – mehr Schaden als Nutzen |
| 1.3.1 Informationen und Beziehungen | 109 | 92 | 17 | Meistens hilfreich, aber das Entfernen von Rollen beeinträchtigt die Struktur |
| 2.1.1 Tastatur | 36 | 22 | 14 | Ausgeblendete Elemente sind über die Tastatur nicht mehr erreichbar |
| Sonstiges (6 Kriterien) | 73 | 69 | 4 | Im Allgemeinen positiv |
| Insgesamt | 776 | 579 (75 %) | 197 (25 %) |
Am besorgniserregendsten ist die Zeile zu WCAG 1.1.1 (Nicht-Text-Inhalte): Von den 108 Korrekturregeln, die auf dieses Kriterium abzielen, 80 sind schädlich – 52 Bilder von AT vollständig ausblenden über hideFromAT(), und 28 kennzeichnen Inhaltsbilder als dekorativ über alt="". Das Overlay blendet Nicht-Text-Inhalte ein weniger barrierefrei, nicht mehr. Das ist genau das Gegenteil von dem, was WCAG 1.1.1 vorschreibt.
Die US-amerikanische Federal Trade Commission bestätigte diese Feststellung, als sie im April 2025 gegen einen Anbieter von Overlay-Tools eine Geldstrafe in Höhe von 1 Million US-Dollar verhängte und erklärte, das Tool „versäume es oder habe es versäumt, grundlegende und wesentliche Website-Komponenten wie Menüs, Überschriften, Tabellen, Bilder, Aufzeichnungen und mehr mit den WCAG-Richtlinien in Einklang zu bringen“.
Behauptung 3: „Overlays können neue Barrieren für die Barrierefreiheit schaffen“
In dem Informationsblatt wird davor gewarnt, dass Overlay-Produkte „Menschen mit Behinderungen aktiv behindern können“.
Wir haben 141 Elemente dokumentiert, die vor Screenreadern verborgen sind, und zwar über hideFromAT(), 115 semantische Rollen, die über role="presentation", 63 Bilder, die stillschweigend als dekorativ gekennzeichnet wurden, über alt=""und 7 Elemente ohne Bedeutung aria-label="true".
Die gravierendsten Beispiele finden sich im Checkout- und Warenkorb-Prozess:
Bei einem Luxus-Einzelhändler sind die Schaltflächen für Amazon Pay, Shop Pay und Klarna für assistive Technologien nicht sichtbar. Ein blinder Nutzer sieht an der Kasse weniger Zahlungsoptionen als ein sehender Nutzer. Bei einem Modehändler sind die Eingabefelder für die Warenkorbmenge und die Aktualisierungsschaltflächen nicht sichtbar – ein blinder Nutzer kann seine Bestellung daher nicht anpassen.
Auf zwei Websites sind die Links zu den Suchergebnissen ausgeblendet – blinde Nutzer haben dadurch Schwierigkeiten, Produkte zu finden. Die Sternebewertungen sind ausgeblendet – blinde Nutzer können die Produktqualität nicht auf dieselbe Weise beurteilen wie sehende Nutzer.
Die Bundesaufsichtsbehörde (BFIT-Bund) bestätigte dieses Muster in ihrer offiziellen gemeinsamen Bewertung: „Es kommt häufig vor, dass der Einsatz solcher Tools zusätzliche Barrieren auf der Website schafft, die ohne das Tool nicht bestanden hätten.“
Behauptung 4: „Die Nutzer verfügen bereits über die erforderlichen Werkzeuge“
In dem Informationsblatt wird argumentiert, dass „die Endnutzer, für die diese Funktionen angeblich gedacht sind, bereits über die erforderlichen Funktionen auf ihrem Computer verfügen“.
Overlay C fügt dem gesamten Dokument einen MutationObserver hinzu und fängt 47 Tastaturereignisse ab. Dies führt zu direkten Konflikten mit Screenreadern, Tools zur Tastaturnavigation und Browser-Erweiterungen, auf die Nutzer mit Behinderungen bereits angewiesen sind.
Wenn ein Screenreader-Nutzer seine Tastaturbefehle und Navigationseinstellungen konfiguriert hat, wird ein Overlay angezeigt, das keydown, keyupund keypress Ereignisse können diese Einstellungen außer Kraft setzen. Die 47 Tastaturereignis-Referenzen von Overlay C in seinem 794-KB-Bundle stellen eine beträchtliche Fläche für die Abfangung von Tastatureingaben dar. Die Engine von Overlay D enthält 282 addEventListener Registrierungen – von denen jede zu Konflikten mit Ereignisbehandlungsroutinen von assistiver Technologie führen könnte.
Behauptung 5: Der „praktische Nutzen“ von Overlay-Widgets wird „weitgehend überschätzt“
In der Informationsübersicht heißt es, dass Widget-Funktionen wie Kontrast- und Textgrößenregler nur einen begrenzten Nutzen bieten, da den Benutzern bereits entsprechende Funktionen auf Systemebene zur Verfügung stehen.
Die von uns analysierten Overlays verursachen pro Sitzung eine kumulative Netzwerkzeit von 4 bis 84 Sekunden, laden pro Seite 500 KB bis 2,9 MB an JavaScript herunter und lösen in einem Fall 83 CORS-Preflight-Anfragen aus, die 38,8 Sekunden reine Protokollverschwendung verursachen – und das alles, um Funktionen bereitzustellen, die Betriebssysteme, Browser und assistive Technologien bereits nativ bieten.
Die schlechteste einzelne Seite von Overlay B generierte 48 Anfragen, die 12,8 Sekunden Netzwerkzeit in Anspruch nahmen. Zum Vergleich: Der Schwellenwert von Googles Core Web Vitals für einen „schlechten“ Wert bei „Largest Contentful Paint“ liegt bei 2,5 Sekunden. Allein das Overlay überschritt diesen Grenzwert um das Fünffache.
Overlay A verbrachte 75 % seiner 33,9 Sekunden Netzwerkzeit für Verhaltensanalysen – 58 Tracking-POST-Anfragen an den eigenen Endpunkt. Die CDN-Anfragen im Zusammenhang mit der Barrierefreiheit machten nur 25 % der Gesamtzeit aus. Der Großteil der Performance-Belastung entfällt auf die Datenerfassung durch den Anbieter, nicht auf die Verbesserung der Barrierefreiheit.
Behauptung 6: „Website-Betreiber sollten robustere, unabhängige und dauerhafte Strategien anwenden“
Das Fact Sheet plädiert für die „Abschaffung von Overlays zur Barrierefreiheit im Web“ zugunsten dauerhafter Strategien zur Barrierefreiheit.
Das Überwachungstool in unserer Studie verkörpert genau diesen Ansatz: Scannen mit axe-core, Melden von Problemen mit standardisierten Regel-IDs und Schweregraden, Beheben der Probleme durch Entwickler im Quellcode. Keine DOM-Änderungen, keine Nutzerverfolgung, kein Risiko für Website-Ausfälle, keine PCI-DSS-Konflikte. Die von uns erfassten Scan-Ergebnisse zeigten Werte zwischen 53,1 und 100, mit konkreten Angaben zu Verstößen (Farbkontrast, Überschriftenreihenfolge, Beschriftung, eindeutige Orientierungspunkte), auf die Entwickler sofort reagieren können.
Die grundlegende Kluft, die unsere Daten aufzeigen, ist architektonischer Natur: Overlays verwalten einen parallelen Satz von Korrekturdefinitionen, der die DOM-Struktur der Website widerspiegelt und bei jeder Bereitstellung veraltet. Ein Überwachungstool scannt das zum Zeitpunkt des Scans vorhandene DOM, meldet seine Ergebnisse und beginnt beim nächsten Scan von vorne. Es gibt keine aufgelaufenen technischen Schulden, keine veralteten Selektoren, keine verwaisten Alt-Text-Einträge und keine Möglichkeit, die falsche Korrektur auf das falsche Element anzuwenden.
Mehr als nur ein Datenblatt: Was unsere Daten zusätzlich bieten
Unsere Untersuchung hat Erkenntnisse zutage gefördert, die über den Rahmen des Overlay-Factsheets hinausgehen:
Konflikt mit PCI DSS 4.0: Die Regeln zur Überlagerungskorrektur zielen aktiv auf Elemente der Zahlungsseite ab – wir haben Selektoren für #cardNumber, #billingState, Zahlungsschaltflächen und Checkout-Formulare. Gemäß der PCI-DSS-Anforderung 6.4.3 (verbindlich ab März 2025) muss für jedes Skript auf einer Zahlungsseite eine dokumentierte Autorisierung und Integritätsprüfung vorliegen. Overlays erfüllen diese Anforderung nicht. Bei einem Luxusgüterkonzern werden identische Selektoren für die Zahlungssteuerung auf zwei Markenwebsites gemeinsam genutzt (96 % Codeüberlappung), wodurch sich der Schadensumfang bei einer Kompromittierung der Lieferkette verdoppelt.
Abtastraten von nur 1,7 %: Wir haben festgestellt, dass die POST-Daten der Analysefunktion eines Overlays ein samplingRate Aus den Daten geht hervor, dass nur 1,7–4,5 % der Sitzungen einen Compliance-Scan auslösen. Die restlichen 95–98 % erhalten DOM-Korrekturen ohne jegliche Überprüfung.
Verstöße gegen die DSGVO: Drei Overlays senden Nutzer-Identifikatoren, Daten zum Geräte-Fingerprinting und Verhaltensanalysen, bevor ein Einwilligungsmechanismus aktiviert werden kann – dies stellt gemäß dem Urteil des EuGH in der Rechtssache „Planet49“ einen automatischen Verstoß dar. Ein Overlay sendet eine persistente UUID, die bei jedem Seitenaufruf identisch ist, wodurch umfassende seitenübergreifende Browsing-Profile erstellt werden können.
Ablehnung durch die deutschen Aufsichtsbehörden: Die BFI-Bund (die deutsche Bundesaufsichtsbehörde) hat Overlays für Konformitätsprüfungen offiziell abgelehnt, und die BIK-Prüfstellen verweigern Websites, die Overlays verwenden, die Vergabe von Konformitätssiegeln. Nach dem deutschen BFSG (Umsetzung der EAA) liegen die Bußgelder zwischen 10.000 € und 100.000 € pro Verstoß.
Einfügen von Formularbezeichnungen zur Laufzeit, das die Formulare verschlechtert: Die Sanierungs-Engine eines Overlays (110 KB) führt zur Laufzeit 24 DOM-Mutationsregeln aus, darunter einen „EmptyControls“-Handler, der versucht, unbeschriftete Formularfelder zu beschriften. Bei einem aktiven Kontaktformular mit sieben Feldern fügte die Engine aria-label aus dem HTML abgeleitete Werte name Attribut anstelle der sichtbaren Beschriftungen – was dazu führt, dass zwei Felder die identische Beschriftung „Name“ haben (aus name="first-name" und name="last-name"), drei Felder, die mit allgemeinen Elementtypen beschriftet sind („Textfeld“, „Einfachauswahl“, „Textbereich“), und zwei, bei denen anstelle der tatsächlich sichtbaren Beschriftung Validierungsbeschreibungen verwendet werden. Der gespeicherte DOM-Snapshot bestätigt, dass jedes geänderte Element den herstellerspezifischen Datenattribut-Marker des Overlays trägt. Der ursprüngliche HTML-Code enthielt zwar korrekte sichtbare Beschriftungen („Vorname“, „Firmenname“ usw.), doch fehlten for Attribute – eine einfache Korrektur im Quellcode, die von der Laufzeit-Engine des Overlays nicht korrekt übernommen wurde.
Korrektur von JSON-Daten, die mit Inhalten fremder Domains verunreinigt sind: Die vorgefertigte Korrektur-JSON-Datei eines Overlays für eine Bank-Website enthielt 7 Alt-Text-Einträge – von denen nur 1 tatsächlich von der eigenen Domain der Bank stammte (mit einem Alt-Text, der aus einem einzigen Leerzeichen bestand). Die übrigen 6 Einträge beschrieben Bilder von völlig unabhängigen Domains: ein polnisches Tool zur Barrierefreiheitstestung (ANDI-Bookmarklet-Symbole), eine chinesische Preisvergleichs-API (Chat-Widget-Symbole), ein russisches Teaser-Werbenetzwerk (Anzeigenmotive) und das Browser-CDN von Xiaomi (Benutzeroberfläche für Übersetzungsaufforderungen). Der Scanner des Overlays hatte diese während einer früheren Sitzung erfasst, in der der Nutzer Browser-Erweiterungen von Drittanbietern und Ad-Injections aktiviert hatte – und die KI-generierten Beschreibungen dauerhaft in der Korrekturdatei der Bank gespeichert, die von jedem Besucher auf jeder Seite heruntergeladen wird. Die JSON-Datei ist auf dem CDN des Overlays ohne Authentifizierung öffentlich zugänglich.
Die Warnungen im „Overlay Fact Sheet“, die von Barrierefreiheitsexperten auf der Grundlage ihrer Erfahrungen verfasst wurden, werden nun durch ausgewertete Produktionsdaten von 14 aktiven E-Commerce-Websites untermauert. Jede wesentliche Aussage bestätigt sich – und die Realität sieht in einigen Bereichen sogar noch schlechter aus, als im Fact Sheet beschrieben.
Behauptung 7: „Overlays untergraben legitime Bemühungen um Barrierefreiheit“
In der Dokumentation zu „Overlay False Claims“ wird davor gewarnt, dass Overlays den „falschen Eindruck erwecken, die Barrierefreiheit sei bereits gewährleistet“, und dass sie „im Widerspruch zu den Grundsätzen des ADA stehen“.
Ein Overlay erfasst lediglich 1,7–4,5 % der Besuchersitzungen. Website-Betreiber erhalten auf Basis dieser geringen Stichprobe Konformitätskennzahlen, was ein falsches Gefühl der Konformität vermittelt, während 95–98 % der Sitzungen nie überprüft werden. Wenn eine Bereitstellung gegen die Fix-Regeln verstößt, kann die Regression aufgrund der geringen Stichprobenrate tagelang unentdeckt bleiben – währenddessen glaubt der Website-Betreiber, dass die Konformität gewährleistet ist.
Das tiefer liegende Problem ist, dass Overlays das Denkmodell von „Wir müssen barrierefreie Produkte entwickeln“ zu „Wir haben ein Widget installiert, das sich um die Barrierefreiheit kümmert“ verschieben. Unsere Daten zeigen, wie das in der Praxis aussieht: Ein Online-Händler für Designerhandtaschen hat 383 Korrekturregeln in seinem Overlay – doch der zugrunde liegende HTML-Code weist nach wie vor alle ursprünglichen Barrierefreiheitsprobleme auf. Wenn das CDN des Overlay-Anbieters für 30 Minuten ausfällt, treten alle Barrieren sofort wieder auf. Die Website wurde nie wirklich behoben.
Behauptung 8: Bedenken hinsichtlich Datenschutz und Nachverfolgung
Auch wenn dies kein Hauptthema des Informationsblatts zu Overlays ist, wurden von Behindertenvertretern Datenschutzbedenken geäußert, da Overlays die Nutzung von assistiver Technologie erkennen können.
Unsere abgefangenen Daten zeigen, dass die Nachverfolgung weit über die Erkennung von AT hinausgeht.
Einschub A: 58 POST-Anfragen pro Sitzung an den eigenen Endpunkt, wobei jede eine Sitzungs-ID enthält (sid), vollständige URL (pg), Seiten-Lade-ID (plid), Gerätekategorie und Ereignistyp. 75 % der gesamten Netzwerkzeit entfallen auf diese Tracking-Aufrufe.
Überlagerung B: Eine persistente UUID (uid) wird in jedem Tunings-POST-Request übermittelt – es handelt sich um denselben Identifikator auf allen Seiten innerhalb der Sitzung, wodurch der Anbieter ein vollständiges Browsing-Profil erstellen kann. Die UUID bleibt unverändert – wir haben festgestellt, dass sie auf allen fünf Seiten einer Telekommunikations-Website gleich blieb.
Überlagerung C: USER-BEHAVIOR-ANALYTICS POST-Daten, einschließlich Domain, Widget-Version und Interaktionsereignissen. Geräte-Fingerprinting über navigator.userAgent, navigator.userAgentDataund navigator.maxTouchPoints. Drei localStorage Schlüssel, deren Zustand über mehrere Sitzungen hinweg erhalten bleibt.
Alle drei lösen ihr Tracking beim Laden der Seite aus – noch bevor ein Einwilligungsmechanismus aktiviert werden kann. Nach dem Urteil des EuGH im Fall Planet49 bedarf nicht unbedingt notwendiges Tracking einer vorherigen ausdrücklichen Einwilligung. Diese Overlays verstoßen auf jeder auf die EU ausgerichteten Website automatisch gegen die DSGVO.
Behauptung 9: „Overlays bergen rechtliche Risiken“
In dem Informationsblatt wird darauf hingewiesen, dass Overlays entgegen den Behauptungen der Anbieter „das rechtliche Risiko nicht beseitigen“ können.
Im Jahr 2024 wurden über 1.023 Unternehmen, die Barrierefreiheits-Widgets einsetzten, wegen Verstößen gegen das ADA verklagt – das waren 25 % aller Klagen im Bereich der digitalen Barrierefreiheit in jenem Jahr. Allein im Februar 2025 wurden 132 Unternehmen, die Overlays einsetzten, verklagt. Die FTC verhängte gegen einen Anbieter eine Geldstrafe in Höhe von 1 Million US-Dollar. Die deutschen Aufsichtsbehörden haben Overlays für die Einhaltung der Vorschriften ausdrücklich abgelehnt. Das rechtliche Risiko ist nicht hypothetisch – es ist dokumentiert, quantifiziert und nimmt zu.
Unsere Datenbank zu Gerichtsverfahren (8.541 ADA-Akten) enthält direkte Rechtsstreitigkeiten, an denen Anbieter von Overlay-Lösungen beteiligt sind: drei Patent-/Geschäftsgeheimnisfälle zwischen zwei Anbietern (2020–2022), eine Sammelklage eines Kunden gegen einen Anbieter (2024) und ein laufendes Gerichtsverfahren gegen einen anderen Anbieter durch ein kleines Unternehmen, das trotz der Nutzung des Overlays verklagt wurde (2024, Antrag auf Klageabweisung 2026 vom Richter abgelehnt).
Das Überwachungstool hat keine Rechtsstreitigkeiten im Zusammenhang mit Verstößen gegen die Barrierefreiheit zu verzeichnen – eine logische Konsequenz: Da es das DOM nicht verändert, kann es keine Barrieren schaffen, die zu Rechtsstreitigkeiten führen könnten.
Die Evidenzlücke ist nun geschlossen
Jahrelang stützten sich das Overlay-Factsheet und die Warnungen der Barrierefreiheits-Community vor Overlays auf Berufserfahrung, Nutzerberichte und manuelle Tests. Kritiker konnten diese als anekdotisch oder voreingenommen abtun. Unsere Forschung schließt diese Lücke, indem sie die erste groß angelegte technische Evidenzbasis liefert: abgefangene Produktionsdaten aus 924 Netzwerkanfragen, 579 extrahierte Quelldateien von 14 aktiven E-Commerce-Websites aus drei unabhängigen Erfassungssitzungen, ergänzt durch gespeicherte DOM-Snapshots, die die genauen Laufzeitänderungen festhalten, die Overlays in Produktionsseiten einfügen.
Jede wesentliche Aussage im Overlay-Fact-Sheet wird durch unsere Daten untermauert. Einige Aussagen fallen im Vergleich zu unseren Erkenntnissen sogar noch zurückhaltender aus. Und die Bereiche, die das Fact-Sheet nicht abdeckt – Konflikte mit dem PCI DSS, Stichprobenraten bei Scans, Tracking vor der Einwilligung gemäß DSGVO sowie die Ablehnung durch deutsche Aufsichtsbehörden – stellen zusätzliche Risikodimensionen dar, die die Barrierefreiheits-Community aus eigener Erfahrung erkannt, bisher jedoch nicht quantifizieren konnte.
Die Beweise finden sich im Code. Der Code ist im abgefangenen Datenverkehr enthalten. Der Datenverkehr stammt von Produktionsseiten, die echte Kunden bedienen. Die Ergebnisse sprechen für sich.