Wir haben jede Anfrage von fünf Barrierefreiheits-Tools abgefangen. Hier erfahren Sie, wie sich diese tatsächlich auf Ihre Website auswirken.

Eine unabhängige technische Prüfung von vier Barrierefreiheits-Overlays und einer reinen Überwachungslösung – was sie tatsächlich bewirken, was sie vor Menschen mit Behinderungen verbergen und warum allein im Jahr 2024 über 1.000 Unternehmen, die Overlays einsetzen, verklagt wurden.

So sind wir vorgegangen: Die Forschungsmethodik

Die meisten Bewertungen von Barrierefreiheits-Overlays stützen sich auf Marketingversprechen, Herstellerangaben oder oberflächliche Tests. Wir haben einen grundlegend anderen Ansatz gewählt: Wir haben jedes einzelne Byte der Daten abgefangen, die zwischen dem Browser und den Servern der einzelnen Tools flossen, die tatsächlichen JavaScript-Korrekturdateien und die Daten zur Fehlerbehebung extrahiert und genau analysiert, wie sich jedes Tool auf das Live-DOM von E-Commerce-Websites in der Produktion auswirkt.

Die technische Ausstattung

Wir haben „mitmproxy“ – einen Open-Source-HTTPS-Proxy – eingesetzt und so konfiguriert, dass er den vollständigen Inhalt aller Anfragen und Antworten für den gesamten Datenverkehr zu den CDN- und API-Domains der Tools erfasst. Wir haben das Root-CA-Zertifikat des Proxys im Browser installiert, um eine transparente HTTPS-Überwachung zu ermöglichen, und anschließend eine eigene Chrome-Instanz gestartet, die ausschließlich über den Proxy geleitet wurde. Wir haben Domain-Filter so konfiguriert, dass nur der Datenverkehr zu den Servern der Barrierefreiheits-Tools erfasst wurde – um sicherzustellen, dass wir nur die von diesen Tools eingefügten Inhalte analysierten und nicht den eigentlichen Datenverkehr der Websites.

Anschließend haben wir 14 aktive E-Commerce-Websites wie ein normaler Nutzer durchstöbert: Wir haben die Startseite geladen, sind zu Produktübersichtsseiten navigiert, haben Produktdetailseiten aufgerufen, Artikel in den Warenkorb gelegt, den Bestellvorgang fortgesetzt, Konto- und Registrierungsseiten besucht und mit Modalen, Karussells und der Suchfunktion interagiert. Jede Browsersitzung wurde als HTTP-Archivdatei (HAR) mit vollständigen Antworttexten aufgezeichnet – im gleichen Format, das Browser intern verwenden, jedoch angereichert mit dem tatsächlichen Inhalt jeder JavaScript-Datei, jedes CSS-Stylesheets, jeder JSON-Konfiguration und jeder API-Antwort, die die Tools bereitstellten.

Nach der Erfassung haben wir Python-Analyseskripte geschrieben, die jeden Antworttext auswerteten, jede Datei nach Tool und Funktion klassifizierten, jeden CSS-Selektor aus den Korrekturdefinitionen extrahierten, jedes DOM-Manipulationsmuster im JavaScript-Code zählten, jede Instanz von Inhalten identifizierten, die vor assistiver Technologie verborgen waren, und jede Korrektur dem betroffenen Seitenbereich zuordneten (Kasse, Warenkorb, Produktliste, Navigation usw.).

Der Proxy erfasste in drei Erfassungssitzungen 924 HTTP-Anfragen mit 579 vollständigen Antworttexten – darunter jedes site-spezifische Korrekturskript, jede Korrektur-JSON-Datei, jede Konfigurationsdatei und jede Analytics-Nutzlast. Außerdem haben wir vollständige DOM-Snapshots von Seiten mit angewendeten Overlay-Änderungen gespeichert, wodurch wir die genauen aria-label-Werte und Vendor-Datenattribute untersuchen konnten, die zur Laufzeit eingefügt wurden. Anschließend haben wir automatisierte Analyseskripte geschrieben, um das JavaScript zu parsen, jedes DOM-Änderungsmuster zu zählen, jeden CSS-Selektor zu extrahieren, jede Korrektur nach Seitenbereich zu klassifizieren und jede Instanz von Inhalten zu identifizieren, die vor assistiver Technologie verborgen wurden.

Was wir analysiert haben

Zu den Websites gehörten große Modehändler, Luxus-Schokoladenmarken, Kofferhersteller, Designer-Handtaschengeschäfte, Spielzeughersteller, ein Telekommunikationsanbieter, eine nationale Bank sowie Marken aus den Bereichen Getränke, Schreibwaren, Uhren und Süßwaren – sowohl auf dem EU- als auch auf dem US-Markt.

Eine kritische Anmerkung: In keinem Barrierefreiheits-Overlay gibt es eine Seitenbezogene Geltungsbereichsdefinition

Eine der überraschendsten Erkenntnisse zeigte sich bereits, bevor wir die Korrekturregeln überhaupt analysiert hatten: Jedes Barrierefreiheits-Overlay lädt sein gesamtes Korrekturset auf jeder einzelnen Seite, unabhängig vom Seitentyp. Korrekturen für den Checkout-Bereich werden auf der Startseite ausgelöst. Regeln zur Warenkorbmenge werden auf der Seite „Über uns“ ausgeführt. Korrekturen für Produktkacheln werden im Anmeldeformular ausgeführt.

Das bedeutet, dass auf der Website des Telekommunikationsanbieters jeder Besucher jeder Seite eine 1,25 MB große JSON-Datei herunterlädt, die 4.974 Bildbeschreibungen und 2.000 PDF-Korrektureinträge enthält – selbst auf Seiten, die überhaupt keine Bilder enthalten. Beim Designer-Handtaschenhändler werden bei jedem Seitenaufruf 383 DOM-Korrekturregeln ausgeführt, die versuchen, Selektoren abzugleichen, die nur auf bestimmten Seitentypen existieren. Wenn ein kassenspezifischer Selektor wie #cardNumber auf der Startseite nicht übereinstimmt, verbraucht die Korrektur-Engine des Overlays dennoch CPU-Leistung für dessen Auswertung – multipliziert mit Hunderten von Regeln führt dies bei jedem Seitenaufruf zu einer messbaren Leistungsverschwendung.

Overlay A erfasst nur 4,5 % der Sitzungen

In den POST-Daten der Overlay-A-Analytik haben wir ein Feld entdeckt, das die tatsächliche Abtastrate beim Scannen angibt:

Eine Stichprobenrate von 0,045 bedeutet, dass bei diesem Modehändler nur 4,5 % der Besuchersitzungen einen Compliance-Scan auslösen. Auf einer anderen Website – einer Luxus-Schokoladenmarke – lag die Rate sogar noch niedriger: bei nur 1,7 %. Es ist möglich, dass der Anbieter des Overlay-Tools während der Einbindung oder Einrichtung einen umfassenderen Erstscan durchführt und anschließend die Stichprobenrate für die laufende Überwachung reduziert. Die Auswirkungen auf den täglichen Betrieb bleiben jedoch erheblich.

Der Code des Startpakets für das Barrierefreiheits-Overlay bestätigt drei Betriebsebenen: „ReleaseVersionReport“ (vollständiger Scan + Bericht – der angegebene Prozentsatz), „ShadowVersionReport“ (Schatten-Scan, keine für den Nutzer sichtbaren Aktionen) und „RunReleaseFixesNoReport“ (Anwendung aller Korrekturregeln, jedoch ohne Durchführung eines Scans). Das bedeutet, dass im Normalbetrieb die überwiegende Mehrheit Ihrer Besucher DOM-Änderungen erhält, die während ihrer Sitzung nicht validiert werden.

Das praktische Risiko besteht darin: Wenn eine Website-Aktualisierung die DOM-Struktur verändert und gegen eine oder mehrere Korrekturregeln verstößt, kann die Regression aufgrund der geringen laufenden Erfassungsrate über einen längeren Zeitraum unentdeckt bleiben. Da nur 1,7–4,5 % der Sitzungen überprüft werden, könnte eine fehlerhafte Korrektur Tausende von Besuchern betreffen, bevor die nächste erfasste Sitzung zufällig auf der betroffenen Seite ausgelöst wird und das Problem meldet. Während dieses Zeitfensters erhält jeder Besucher veraltete oder falsch zugeordnete Korrekturen – und weder der Website-Betreiber noch der Overlay-Anbieter sind sich des Problems möglicherweise bewusst.

Die Ergebnisse: Korrekturen an Regeln und DOM-Änderungen

Overlay A: JavaScript-Korrekturdateien pro Website

Dieses Overlay verwaltet für jede Client-Website eine eigene JavaScript-Korrekturdatei, die Regeln enthält, die auf bestimmte CSS-Selektoren abzielen. Bei den fünf von uns analysierten Websites haben wir Folgendes festgestellt:

Wir haben außerdem festgestellt, dass 7 Fälle wo die Zeichenkette "true" wurde als aria-label – Ein Programmierfehler, bei dem anstelle von beschreibendem Text ein boolescher Wert übergeben wurde. Screenreader geben „Button, true“ aus – was völlig bedeutungslos ist. Auf einer anderen Website war „Search“ in einer eingefügten Beschriftung fälschlicherweise als „Seacrh“ geschrieben.

Overlay B: KI-generierter Alternativtext in großem Umfang

Dieses Overlay lädt umfangreiche JSON-Dateien mit von KI generierten Bildbeschreibungen herunter. Auf drei Websites:

Beispiele aus den Sanierungsdaten:

323 Beschreibungen waren länger als 125 Zeichen – was zu übermäßigen Ansagen durch Screenreader führte, bei denen der Vorleser pro Bild 10 bis 15 Sekunden lang vorlas. 156 begannen unnötigerweise mit „Bild von“ – ein WCAG-Anti-Pattern, da Screenreader den Elementtyp ohnehin bereits ansagen.

Überwachungstool: Keine Änderungen – im Quellcode überprüft

Was „Vor AT verbergen“ für echte Nutzer bedeutet

Wenn ein Overlay ein Element vor assistiver Technologie verbirgt, bleibt das Element auf dem Bildschirm sichtbar, wird für Screenreader jedoch vollständig unsichtbar. Wir haben jedes verborgene Element nach dem Seitenbereich klassifiziert, auf den es sich auswirkt:

Daten aus den tatsächlichen „active.js“-Korrekturdateien der einzelnen Websites, die über mitmproxy extrahiert wurden. Jede Zahl steht für einen eindeutigen CSS-Selektor, auf den „hideFromAT()“ abzielt.

Auf der Checkout-Seite eines Luxus-Einzelhändlers gehörten zu den Elementen, die vor Screenreadern verborgen waren:

So sorgen Overlay-Tools für Barrierefreiheit für ein zweigeteiltes Einkaufserlebnis: Sehende Nutzer sehen alle Zahlungsoptionen und können zwischen Kreditkarte, PayPal, Amazon Pay, Shop Pay und Klarna wählen. Blinde Nutzer finden hingegen nur die Zahlungsmethoden, die das Overlay nicht ausgeblendet hat. Bei einem Modehändler waren sowohl das Feld zur Eingabe der Stückzahl im Warenkorb als auch die Schaltfläche zum Aktualisieren ausgeblendet – ein blinder Nutzer konnte zwar Artikel hinzufügen, aber die Stückzahlen nicht ändern.

Dies wirft eine grundlegende Frage auf: Macht ein Overlay, das Zahlungsschaltflächen vor blinden Nutzern verbirgt, die Website barrierefreier oder weniger barrierefrei?

Auswirkungen auf die Leistung

Was geschieht nach der Bereitstellung einer Website?

Das vielleicht heimtückischste Risiko von Overlay-Tools wird erst mit der Zeit sichtbar: Die Korrekturen verlieren still und leise an Wirksamkeit. Im Gegensatz zu einem JavaScript-Fehler, der zu einem sichtbaren Absturz führt, oder einem fehlerhaften Layout, das jemand bemerkt, verursacht eine veraltete Overlay-Korrektur weder einen Fehler noch eine Warnmeldung und auch keine sichtbare Veränderung. Sie funktioniert einfach nicht mehr – und die Barriere für die Barrierefreiheit, die sie verdeckt hat, taucht wieder auf, ohne dass es jemand bemerkt.

Um dies zu verstehen, sollten Sie sich vor Augen führen, wie sich die einzelnen Overlay-Typen in die DOM-Struktur Ihrer Website einbinden.

Selektorbasierte Korrekturen: Die Uhr tickt

Overlay A verwaltet – wie die meisten Overlay-Lösungen für Barrierefreiheit – JavaScript-Korrekturdateien für jede einzelne Website, die Regeln wie diese enthalten (rekonstruiert anhand des tatsächlich erfassten Codes):

Diese Regel zielt auf die Zurück-Schaltfläche eines Slick-Karussells ab und verwendet dabei drei CSS-Klassen: .js-recommendation_carousel, .slick-prevund .slick-arrow. Jeder Teil dieses Selektors ist anfällig. Wenn das Website-Team die Klasse des Karussell-Containers umbenennt, von Slick zu Splide oder Swiper wechselt oder einfach die Slick-Bibliothek auf eine Version aktualisiert, die die Konvention zur Klassennamensgebung ändert – trifft der Selektor auf nichts mehr. Die Schaltfläche verliert ihre Beschriftung „Vorherige Folie“. Nutzer von Bildschirmleseprogrammen können sie nicht mehr identifizieren.

An den fünf Standorten, die wir für Overlay A analysiert haben, haben wir festgestellt, dass 98 % aller Selektoren enthalten frameworkspezifische Klassennamen – Klassen, deren Name mit .js-, .b-, .chakra-, .splide__oder CSS-in-JS-Hashes wie .css-acuo7n. Dabei handelt es sich nicht um stabile, semantische Bezeichner – es sind Implementierungsdetails, die sich mit jedem Framework-Update, jeder Komponentensanierung oder jeder Änderung am Build-System ändern.

Bei einem Händler für Designer-Handtaschen haben wir Selektoren entdeckt, die auf Chakra-UI-Komponenten abzielen. Chakra UI führt in Hauptversionen grundlegende Änderungen ein – Klassennamen, Komponentenstruktur und ARIA-Muster entwickeln sich weiter. Wenn diese Website ein Chakra-Upgrade durchführt, werden möglicherweise Hunderte von Overlay-Korrekturregeln unbemerkt unwirksam. Der Overlay-Anbieter muss dann die neue DOM-Struktur manuell überprüfen, jeden betroffenen Selektor neu schreiben und aktualisierte Korrekturdateien bereitstellen. In der Zeit zwischen der Bereitstellung der Website und dem Update des Overlay-Anbieters läuft die Website mit veralteten Korrekturen – einige bewirken nichts, andere werden möglicherweise auf die falschen Elemente angewendet.

URL-basierte Korrekturen: Noch anfälliger

Overlay B ordnet jedem Alt-Text-Eintrag die genaue Bild-URL zu. Wir haben Einträge wie die folgenden gefunden:

Beachten Sie die Anfälligkeit: Die URL enthält eine Geräte-ID (13555), eine Miniaturbildgröße (86x86) sowie einen Dateinamen, der den Produktnamen enthält. Diese Angaben können unabhängig voneinander geändert werden. Wenn das CMS Miniaturansichten in einer anderen Größe neu generiert, wird die thumb_86x86 Ein Teil der URL ändert sich, und der Eintrag passt nicht mehr. Wenn das Produktteam ein neues Foto mit einem anderen Dateinamen hochlädt, wird der Eintrag verwaist. Wenn die Website ihre Medien auf ein CDN mit einer anderen Domain migriert, wird jeder einzelne Eintrag in der 1,17 MB großen JSON-Datei zu Ballast – und jedes Bild auf der Website verliert gleichzeitig seinen Alt-Text.

Das schlimmste Szenario ist ein teilweiser Abgleichfehler: Einige Bilder behalten ihre alten URLs (und erhalten einen Alt-Text), während neue oder aktualisierte Bilder keinem Eintrag entsprechen (und nichts erhalten). Das Ergebnis ist ein uneinheitliches Erlebnis, bei dem manche Bilder beschrieben werden, andere jedoch stillschweigend übersprungen werden – was für einen Screenreader-Nutzer weitaus verwirrender ist als das einheitliche Fehlen von Alt-Text.

Korrekturen auf globaler Ebene: Das Kaskadenproblem

Der Ansatz von Overlay C – das Anbringen eines MutationObservers am gesamten Dokument und das Anwenden generischer Korrekturen auf alle Elemente bestimmter Typen (a, button, input, img, h1) – erzeugt ein anderes, aber ebenso gefährliches Fehlermuster. Anstatt stillschweigend zu versagen, wenn Selektoren veralten, führt dieses Overlay kämpft aktiv mit neuem Code.

Stellen Sie sich ein gängiges Szenario vor: Das Website-Team stellt eine neue barrierefreie Modal-Dialogkomponente bereit, die Fokus-Trapping, „Escape-to-Close“ und ARIA-Attribute korrekt implementiert. Der MutationObserver des Overlays erkennt die neuen DOM-Elemente, gleicht sie mit seinen generischen Regeln ab und wendet – sobald er Elemente findet, die seinen Mustern entsprechen – seine eigene Fokusverwaltung, Tastaturbehandlungsroutinen und ARIA-Attribute zusätzlich zur bestehenden, korrekten Implementierung der Komponente an. Das Ergebnis sind doppelt gefangener Fokus, doppelte Tastaturbehandler und widersprüchliche ARIA-Attribute. Das Modal, das vor dem Laden des Overlays einwandfrei funktionierte, verhält sich nun unvorhersehbar.

Dies ist kein rein theoretisches Problem. Framework-Komponentenbibliotheken wie Radix UI, Headless UI und Chakra UI investieren erheblichen technischen Aufwand in die korrekte Umsetzung von ARIA. Ein Overlay, das pauschal seine eigenen ARIA-Attribute auf alle button und a Elemente dürften mit diesen bewährten Implementierungen in Konflikt geraten, was dazu führt, dass Komponenten nicht korrekt zugänglich sind weniger zugänglich.

Das Überwachungstool: Nichts, was kaputtgehen könnte

Das von uns analysierte Überwachungstool verfügt weder über selektorbasierte Korrekturen noch über URL-gebundene Einträge, MutationObserver oder generische Elementauswahl. Wenn auf der Website neuer Code bereitgestellt wird, vergleicht der nächste Scan des Überwachungstools das neue DOM automatisch mit dem standardisierten Regelsatz von axe-core und meldet etwaige neue Verstöße – ohne irgendetwas zu ändern. Die Scan-Ergebnisse werden im Dashboard des Tools mit Schweregraden, der Anzahl der betroffenen Elemente und standardisierten WCAG-Regel-IDs angezeigt. Entwickler überprüfen die Ergebnisse und implementieren Korrekturen in ihrer eigenen Codebasis, wo diese Korrekturen eine Codeüberprüfung, automatisierte Tests, eine Staging-Validierung und eine kontrollierte Bereitstellung durchlaufen.

Dieser Prozess ist von Natur aus widerstandsfähig gegenüber Änderungen: Das Tool scannt das zum Zeitpunkt des Scans vorhandene DOM, meldet gefundene Probleme und beginnt beim nächsten Scan von vorne. Es gibt keine angesammelten technischen Schulden in Form von Korrekturdefinitionen, keine veralteten Selektoren, keine verwaisten Alt-Text-Einträge und keine Möglichkeit, die falsche Korrektur auf das falsche Element anzuwenden.

Was geht schief, wenn man die Anwendung neu bereitstellt?

Jede Korrektur am Barrierefreiheits-Overlay ist an die aktuelle DOM-Struktur der Website gekoppelt. Wir haben festgestellt, dass 98 % der Selektoren eines Overlays beziehen sich auf frameworkspezifische Klassennamen – Klassen wie .chakra-, .splide__, .js-, .b-und CSS-in-JS-Hashes wie .css-acuo7n die sich bei jedem Build ändern.

Das Überwachungstool zeigt in jeder Zeile „Nicht betroffen“ an, da es keine auf Selektoren basierenden Korrekturen enthält. Es gibt nichts, was veralten könnte, nichts, was auf das falsche Element abzielen könnte, nichts, was kaputtgehen könnte.

DSGVO, Datenschutz und das Problem der Einwilligung

Unsere Analyse hat bestätigt, dass drei der vier Barrierefreiheits-Overlays Daten an externe Server senden, bevor eine Interaktion mit dem Einwilligungsbanner möglich ist:

Gemäß dem Urteil des EuGH im Fall „Planet49“ bedarf das nicht unbedingt erforderliche Tracking einer vorherigen Einwilligung durch Opt-in. Zwei Overlays setzen bei der ersten Netzwerkanfrage dauerhafte Identifikatoren – noch bevor ein Einwilligungsmechanismus aktiviert werden kann. Für Websites, die sich an Nutzer in der EU richten, bedeutet dies automatisch einen Verstoß gegen die DSGVO.

Die rechtliche Lage

Im April 2025 schloss die US-amerikanische Federal Trade Commission (FTC) einen Vergleich in Höhe von 1 Million US-Dollar mit einem der in unserer Studie untersuchten Anbieter von Barrierefreiheits-Overlays ab, da dieser fälschlicherweise behauptet hatte, sein KI-gestütztes Tool könne jede Website WCAG-konform machen. Die FTC stellte fest, dass das Tool grundlegende Website-Komponenten – Menüs, Überschriften, Tabellen, Bilder und Aufzeichnungen – nicht barrierefrei machte. In einem angeführten Beispiel erhielt ein Foto von Filet Mignon die KI-generierte Beschreibung „Braunes Brot auf einem weißen Keramikteller“.

Branchenstatistiken zufolge wurden in 25 % aller Rechtsstreitigkeiten im Bereich der digitalen Barrierefreiheit im Jahr 2024 Overlay-Widgets ausdrücklich als Hindernisse – und nicht als Lösungen – genannt. In der ersten Hälfte des Jahres 2025 gab es weiterhin monatlich über 100 Klagen gegen Unternehmen, die Overlays einsetzen. Zwei der in unserer Studie untersuchten Overlay-Anbieter waren direkt in Rechtsstreitigkeiten verwickelt: einer in drei separaten Patent-/Geschäftsgeheimnisverfahren und ein anderer in einer Sammelklage eines Kleinunternehmens, das trotz der Nutzung des Overlays verklagt wurde.

Das Überwachungstool in unserer Studie hat keine Rechtsstreitigkeiten im Zusammenhang mit Barrierefreiheitsmängeln zu verzeichnen – eine logische Folge seiner Architektur: Da es das DOM niemals verändert, kann es keine Barrieren für die Barrierefreiheit verursachen.

Ein Blick in den Code: Was ändern Overlays tatsächlich?

Um das Ausmaß der DOM-Manipulation zu erfassen, haben wir alle Änderungsmuster im JavaScript der einzelnen Tools gezählt. Die Unterschiede sind dramatisch:

Besondere Aufmerksamkeit verdient Overlay C. Sein 794 KB großes monolithisches Bundle fügt ein MutationObserver zu document.documentElement mit der Konfiguration {subtree: true, childList: true, attributes: true, attributeOldValue: true}. Das bedeutet jede einzelne DOM-Änderung auf der gesamten Seite – sei es durch die Virtual-DOM-Abgleichung von React, ein A/B-Test-Skript, ein Chat-Widget oder das eigene JavaScript der Website – löst den Observer des Overlays aus, der daraufhin seine Korrekturen neu auswertet und möglicherweise erneut anwendet. Nach einer Neubereitstellung der Website führt dies zu einer Kaskade von erneuten Korrekturversuchen bei Elementen, die möglicherweise bereits korrekt barrierefrei sind, wodurch korrekte ARIA-Attribute unter Umständen durch falsche überschrieben werden.

Wir haben bestätigt, dass Overlay C USER-BEHAVIOR-ANALYTICS POST-Anfragen an den eigenen Log-Empfänger, wobei die Nutzdaten die Website-Domain, die Widget-Version, die Benutzersprache und Interaktionsereignisse enthalten. In Kombination mit localStorage Persistenz und Geräte-Fingerprinting über navigator.userAgent und navigator.maxTouchPointsDies stellt einen Datenverarbeitungsvorgang dar, von dem die meisten Website-Betreiber gar nicht wissen, dass er stattfindet.

Das Problem mit der JSON-Korrektur

Overlay B lädt eine riesige JSON-Datei herunter (bis zu 1,17 MB für eine Telekommunikations-Website), die alle Fix-Definitionen enthält. Auf einer Website haben wir beobachtet, dass diese Datei innerhalb einer einzigen Browsersitzung viermal abgerufen wurde – 4,7 MB Bandbreite für eine Datei, die eigentlich zwischengespeichert worden sein sollte. Die JSON-Datei enthält 11 Kategorien, doch der überwiegende Teil besteht aus KI-generierten Bildbeschreibungen: 4.974 von 6.975 Einträgen für einen Standort. Jeder Eintrag ist mit einer bestimmten Bild-URL verknüpft – wenn das CMS eine Datei umbenennt, die Abmessungen der Miniaturansichten ändert oder CDN-Domains migriert, passen die Einträge plötzlich nicht mehr. Die Ersatzbilder erhalten überhaupt keinen Alt-Text, wodurch die Seite weniger barrierefrei ist als vor der Installation des Overlays.

Dieses Overlay stellt zudem Laufzeitmodule bereit, die die Seite aktiv umschreiben: eine 110 KB große Korrektur-Engine, einen 23 KB großen Navigationsmenü-Helper, der die Tastatursteuerung des Menüs umstrukturiert, einen 5,8 KB großen Karussell-Patch sowie einen 53 KB großen clientseitigen Scanner, der anstelle der branchenüblichen „axe-core“-Engine eine proprietäre Logik verwendet – was bedeutet, dass seine Ergebnisse nicht unabhängig überprüft werden können.

Die transparenteste Überlagerung – dennoch riskant

Overlay D wies die transparenteste Architektur auf: für Menschen lesbare JSON-Konfigurationsdateien mit expliziten Schaltern zum Aktivieren und Deaktivieren. Optionen wie addAriaHidden, overwriteAltund adjustMetaViewport wurden ausdrücklich auf false. Die zugrunde liegende Engine (649 KB) enthält jedoch 216 setAttribute Anrufe, 47 aria-hidden Literaturverzeichnis, 282 addEventListener Anmeldungen und 9 MutationObserver Fälle. Die Engine unterstützt aggressive DOM-Änderungen, selbst wenn die aktuelle Konfiguration konservativ ist – eine Änderung der herstellerseitigen Konfiguration könnte risikobehaftete Funktionen aktivieren, ohne dass der Betreiber der Website davon Kenntnis hat.

Wir haben standortspezifische Selektoren gefunden, die JavaScript-generierte Hash-Endungen enthalten, wie zum Beispiel button.topHeader__infoButton.js-exclusions85ada2b86bb632424e3ad77c14 die sich bei jedem Build ändern, sowie URL-Selektoren für soziale Medien, die veraltet sind, sobald die Website ihre Facebook- oder Instagram-Links aktualisiert.

Das Europäische Gesetz zur Barrierefreiheit: Warum Overlays die Anforderungen des EAA nicht erfüllen

Ab dem 28. Juni 2025 schreibt das Europäische Gesetz zur Barrierefreiheit (EAA) vor, dass digitale Produkte und Dienste, die in der EU verkauft werden, Barrierefreiheitsstandards erfüllen müssen, die sich an der Norm EN 301 549 orientieren, welche wiederum auf die WCAG 2.1 AA verweist. Im Gegensatz zum ADA – das in erster Linie durch private Klagen durchgesetzt wird – wird die EAA von nationalen Marktüberwachungsbehörden durchgesetzt, die befugt sind, Geldbußen zu verhängen, Abhilfemaßnahmen anzuordnen und nicht konforme Produkte vom Markt zu nehmen.

Deutschlands offizielle Ablehnung von Overlay-Tools

Deutschland hat von allen Ländern die eindeutigste regulatorische Position zu Overlay-Tools für Barrierefreiheit eingenommen. Die BFIT-Bund (Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik) hat gemeinsam mit allen Überwachungsstellen auf Landesebene eine gemeinsame Stellungnahme veröffentlicht, in der Overlay-Tools für die Einhaltung der Barrierefreiheitsvorschriften ausdrücklich abgelehnt werden:

Am 12. März 2025 bekräftigte der Ausschuss für barrierefreie Informationstechnik (gegründet gemäß § 5 BITV 2.0) diese Position in seiner Sitzung und stellte mit Besorgnis fest, dass öffentliche Stellen weiterhin versuchen, ihren Barrierefreiheitsverpflichtungen durch die Einbindung von Overlay-Tools nachzukommen. Der Ausschuss kam zu dem Schluss, dass „eine vorübergehende barrierefreie Darstellung einer Website durch Software – möglicherweise erst nach Konfiguration der Einstellungen durch den Nutzer – für die Dauer seines Besuchs nicht den Anforderungen der geltenden gesetzlichen Bestimmungen entspricht.“

Der Ausschuss warnte ausdrücklich davor, dass öffentliche Einrichtungen, die Overlay-Tools einsetzen, Gefahr laufen, die Barrierefreiheit ihrer Websites zu verschlechtern statt zu verbessern – was zu einer „Verschlechterung der Barrierefreiheit“ führt. Dies deckt sich direkt mit unserer technischen Feststellung, dass 26 % der Overlay-Korrekturregeln neue Verstöße gegen die WCAG verursachen.

BIK-Prüfsiegel: Verweigert für Websites, die Overlays verwenden

Das deutsche BIK-Prüfnetzwerk – bestehend aus akkreditierten Stellen, die Websites anhand der BITV 2.0, EN 301 549 und WCAG 2.1 AA bewerten – hat eine operative Maßnahme ergriffen: Websites, die Overlay-Tools verwenden, können das BIK-Prüfsiegel nicht erhalten. Die Prüfstellen erklärten, dass sie bei Vorhandensein eines Overlays keine zuverlässige Konformitätsbewertung vornehmen können, da das Overlay das DOM zur Laufzeit in einer Weise verändert, die die Testergebnisse unzuverlässig macht. Das BIK-Siegel wird in ganz Deutschland als Nachweis für die Konformität mit BITV 2.0 weit verbreitet verwendet – und steht nun keiner Website mehr zur Verfügung, die ein Overlay nutzt.

Dies ist kein rein theoretisches politisches Problem. Es bedeutet, dass eine deutsche E-Commerce-Website, die eine der vier von uns getesteten Overlay-Lösungen verwendet, die auf dem deutschen Markt übliche Konformitätsbescheinigung nicht erhalten kann.

Bestätigung auf europäischer Ebene

Diese rechtliche Position gilt nicht nur für Deutschland. Das Europäische Behindertenforum und die International Association of Accessibility Professionals haben 2023 eine gemeinsame Erklärung veröffentlicht, in der sie darauf hinweisen, dass Overlays Websites weder barrierefrei machen noch dafür sorgen, dass sie den europäischen Rechtsvorschriften zur Barrierefreiheit, einschließlich des Europäischen Barrierefreiheitsgesetzes, entsprechen. Auch die Europäische Kommission hat sich zu den Konformitätsangaben von Overlays geäußert und ist zu dem Schluss gekommen, dass Overlays die Einhaltung der geltenden Standards nicht gewährleisten können.

Nach dem deutschen BFSG (Barrierefreiheitsstärkungsgesetz – die deutsche Umsetzung der EAA, in Kraft seit dem 28. Juni 2025) können Marktüberwachungsbehörden Geldbußen in Höhe von 10.000 bis 100.000 Euro pro Verstoß verhängen. Die Bewertung durch das BFIT-Bund und die Weigerung des BIK-Prüfnetzwerks, Websites zu zertifizieren, die Overlays verwenden, bedeuten faktisch, dass Overlay-Tools in Deutschland keinerlei rechtlichen Schutz bieten – und das Risiko von Durchsetzungsmaßnahmen sogar aktiv erhöhen können.

Sicherheit und Risiken in der Lieferkette

Jedes Overlay-Tool fügt JavaScript von Drittanbietern in den globalen Bereich Ihrer Produktionsseiten ein. Dieses JavaScript wird mit denselben Berechtigungen wie Ihr eigener Code ausgeführt – es kann jedes DOM-Element lesen und ändern, Formularübermittlungen abfangen, auf Cookies zugreifen, Nutzer umleiten und Daten abziehen. Die sicherheitstechnischen Auswirkungen dieser Vorgehensweise sind erheblich und werden oft übersehen.

Die Angriffsfläche

Betrachten wir einmal die Lieferkette: Wenn Sie Ihrer Website ein Barrierefreiheits-Overlay hinzufügen, gewähren Sie einem Drittanbieter kontinuierlichen, uneingeschränkten Schreibzugriff auf Ihr Live-Produktions-DOM. Das CDN des Anbieters stellt das JavaScript bereit, das Team des Anbieters wartet den Code, und die Bereitstellungspipeline des Anbieters überträgt Aktualisierungen direkt auf Ihre Website – ohne Ihre Codeüberprüfung, ohne Ihren Qualitätssicherungsprozess und ohne Ihre Genehmigung.

Wird das CDN des Overlay-Anbieters kompromittiert, kann der Angreifer bösartigen Code in jede Website einschleusen, die dieses Overlay nutzt. Wenn ein Mitarbeiter des Anbieters ein fehlerhaftes Update bereitstellt, sind alle Kundenwebsites gleichzeitig betroffen. Wird der API-Endpunkt des Anbieters gekapert, können die an Ihre Website übermittelten JSON-Dateien zur Fehlerbehebung oder Konfigurationsdaten manipuliert werden, um Formularfelder zu ändern, Links umzuleiten oder Phishing-Inhalte einzuschleusen.

Das Ausmaß dieses Risikos steht in direktem Zusammenhang mit dem DOM-Fußabdruck des Overlays:

Overlay B weist die größte Risikofläche in der Lieferkette auf: 228 API-Aufrufe pro Sitzung über drei externe Domains hinweg, mit einer 1,17 MB großen JSON-Nutzlast, die festlegt, wie das DOM geändert werden soll. Eine kompromittierte API-Antwort könnte die Remediation-Engine anweisen, beliebige Inhalte in ein beliebiges Element auf der Seite einzufügen. Das 1.285 KB große monolithische Bundle von Overlay C ist die größte einzelne JavaScript-Nutzlast – und da es minimiert und verschleiert ist, können weder der Website-Betreiber noch ein Sicherheitsprüfer sinnvoll überprüfen, was es zur Laufzeit ausführt.

Einhaltung der PCI-DSS-Vorschriften: Ein direkter Konflikt

Für jede E-Commerce-Website, die Kreditkartenzahlungen abwickelt, ist die Einhaltung der PCI-DSS-Vorgaben keine Option. Unsere Untersuchungen zeigen zudem, dass ein direkter Konflikt zwischen der Architektur von Overlay-Tools für Barrierefreiheit und den PCI-DSS-Anforderungen besteht.

Die Anforderung 6.4.3 des PCI DSS (eingeführt in PCI DSS v4.0, verbindlich ab dem 31. März 2025) schreibt vor, dass alle Skripte auf Zahlungsseiten, die im Browser des Kunden geladen und ausgeführt werden, wie folgt verwaltet werden müssen: Es muss ein Verfahren implementiert werden, um zu überprüfen, ob jedes Skript autorisiert ist, die Integrität jedes Skripts muss gewährleistet sein, und es muss ein Verzeichnis aller Skripte geführt werden, das eine schriftliche Begründung für die Notwendigkeit jedes einzelnen Skripts enthält.

Unsere Analyse hat bestätigt, dass Overlay-Fix-Regeln gezielt auf DOM-Elemente von Zahlungsseiten auf mehreren Websites abzielen:

Dies ist kein theoretisches Risiko – es handelt sich um konkrete Skripte, die wir aus Produktionsumgebungen extrahiert haben und die Kreditkartennummernfelder, Auswahlfelder für Rechnungsadressen, Schaltflächen von Zahlungsanbietern und Container für Checkout-Formulare aktiv verändern. Gemäß PCI DSS 6.4.3 erfordert jedes einzelne dieser Skripte von Drittanbietern eine dokumentierte Genehmigung, eine Integritätsprüfung und eine schriftliche Begründung.

Überlegen Sie sich, was das Skript eines Overlay-Anbieters auf Ihrer Checkout-Seite bewirken kann:

Das Überwachungstool hingegen verfügt über keinerlei Schreibzugriff auf das DOM. Sein 4,2 KB großes Skript kann weder Formularfelder ändern noch Eingabeereignisse abfangen und hat keinen Zugriff auf Elemente des Bezahlvorgangs oder die Möglichkeit, diese zu verändern. Selbst wenn das CDN des Überwachungsanbieters kompromittiert würde, erhielte der Angreifer lediglich Zugriff auf ein Skript, das lediglich die Seiten-URL und den Gerätetyp auslesen kann – nicht jedoch auf eines, das das Bezahlformular umschreiben könnte. Im Hinblick auf den Anwendungsbereich des PCI DSS verursacht das Überwachungstool keine zusätzliche Angriffsfläche auf Zahlungsseiten.

Die Frage der Diskriminierung

Dies ist das Diskriminierungsproblem, das jedem Overlay zur Barrierefreiheit zugrunde liegt: Das beunruhigendste Ergebnis ist kein technischer Mangel – es ist ein Muster, bei dem behinderten Nutzern systematisch der Zugang zu Funktionen verwehrt wird, die sehende Nutzer als selbstverständlich ansehen.

Wenn ein Overlay eine Amazon-Pay-Schaltfläche im Barrierefreiheitsbaum verdeckt, sieht ein blinder Nutzer weniger Zahlungsoptionen als ein sehender Nutzer. Wenn das Eingabefeld für die Warenkorbmenge ausgeblendet ist, kann ein blinder Nutzer seine Bestellung nicht anpassen. Wenn Links zu Suchergebnissen ausgeblendet sind, wird die Produktsuche beeinträchtigt. Wenn Sternbewertungen ausgeblendet sind, kann ein blinder Nutzer die Produktqualität nicht so beurteilen wie ein sehender Nutzer.

Das sind keine Ausnahmefälle – es handelt sich um zentrale E-Commerce-Abläufe, die gerade durch jene Tools gestört werden, die versprechen, sie zugänglich zu machen.

Die Behindertengemeinschaft macht seit Jahren lautstark darauf aufmerksam. Das „Overlay Fact Sheet“ – unterzeichnet von Hunderten von Barrierefreiheitsexperten – warnt davor, dass Barrierefreiheits-Overlays „den zugrunde liegenden HTML-Code nicht reparieren“ und „Menschen mit Behinderungen oft aktiv behindern“. Unsere technische Analyse liefert den Beweis: 141 vor Screenreadern versteckte Funktionselemente, 7 eingefügte sinnlose Labels und 5.066 ungeprüfte KI-Beschreibungen, die in die Produktion übernommen wurden – und das auf nur 14 Websites.

Für Website-Betreiber stellt sich nicht die Frage, ob Overlays „gut genug“ sind – vielmehr geht es darum, ob der Einsatz eines Tools, das ein zweigeteiltes Nutzererlebnis schafft, zu rechtfertigen ist: eine Version für sehende Nutzer, die den vollen Funktionsumfang nutzen können, und eine gefilterte, fehlerhafte, manchmal unsinnige Version für Nutzer mit Behinderungen.

Auswirkungen auf die ADA-Konformität: Helfen diese Korrekturen tatsächlich?

Das zentrale Versprechen jedes Overlays besteht darin, die ADA-Konformität zu verbessern, indem WCAG-Verstöße zur Laufzeit behoben werden. Unsere Analyse deckt jedoch ein beunruhigendes Paradoxon auf: Ein erheblicher Prozentsatz der Overlay-Korrekturen führt aktiv zu neuen WCAG-Verstößen, während sie versuchen, bestehende zu beheben.

Wir haben jede erfasste Korrekturregel aus Overlay A dem jeweiligen WCAG 2.1-Erfolgskriterium zugeordnet, auf das sie abzielt. Von den 776 Regeln, die zugeordnet werden konnten, lassen sich die Ergebnisse in zwei Kategorien einteilen: Korrekturen, die tatsächlich ein WCAG-Problem beheben, und Korrekturen, die dabei einen neuen Verstoß gegen die WCAG verursachen.

Fairerweise muss man sagen, dass drei Viertel der erfassten Korrekturen echte Verbesserungen sind – das Hinzufügen fehlender Schaltflächenbeschriftungen, die Korrektur von Überschriftenhierarchien, die Berichtigung von Autocomplete-Attributen und die Implementierung von Modal-Fokusfallen. Das verbleibende Viertel ist jedoch ausgesprochen schädlich, und dieser Schaden trifft unverhältnismäßig stark genau jene Nutzer, denen das Tool angeblich helfen soll.

Inwiefern verstößt jedes dieser risikobehafteten Muster gegen die WCAG?

Das Problem ist nicht nur, dass diese Korrekturen fehlschlagen – vielmehr führen sie zu Verstößen gegen bestimmte WCAG-Erfolgskriterien, die vor dem Anwenden des Overlays nicht bestanden. In einem ADA-Verfahren kann der Sachverständige des Klägers diese durch das Overlay verursachten Verstöße als Beweis dafür anführen, dass die Website Menschen mit Behinderungen diskriminiert.

Overlay B: KI-Alt-Text und WCAG 1.1.1

WCAG 1.1.1 schreibt vor, dass Nicht-Text-Inhalte über eine „Textalternative verfügen müssen, die denselben Zweck erfüllt“. Ein KI-generierter Alt-Text, der ein Firmenlogo als „ein blaues und gelbes Zeichen“ beschreibt, erfüllt nicht den gleichwertigen Zweck – der Zweck eines Logos ist die Markenidentifikation, nicht die Beschreibung der Farben. Ein Alt-Text wie „Text“ für ein Werbebanner oder „Stadt“ für ein Hero-Bild verfehlt dasselbe Kriterium auf andere Weise – er ist so vage, dass er nutzlos ist.

Von den 5.068 KI-generierten Alt-Texten, die wir aus Overlay B erfasst haben, waren 241 kürzer als 15 Zeichen (zu vage, um nützlich zu sein), 323 länger als 125 Zeichen (was gegen die Best Practices für die Barrierefreiheit bei Screenreadern verstößt) und 156 begannen mit „Bild von“ oder „Foto von“ (überflüssig, da Screenreader den Elementtyp bereits ansagen). Nur 2 waren von einem menschlichen Prüfer genehmigt worden.

Nach den Standards für ADA-Rechtsstreitigkeiten würde der Barrierefreiheitsexperte eines Klägers dies als Verstoß gegen WCAG 1.1.1 einstufen – das in ADA-Klagen zur Barrierefreiheit im Internet am häufigsten angeführte Kriterium. Das Overlay behebt den Verstoß nicht; es ersetzt lediglich eine Form der Nichtkonformität (fehlender Alt-Text) durch eine andere (unzutreffender oder vager Alt-Text) und vermittelt dem Betreiber der Website gleichzeitig den falschen Eindruck, die Vorschriften einzuhalten.

Overlay B: Einfügen von Formularbezeichnungen zur Laufzeit – wenn das „Beheben“ das Problem noch verschlimmert

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.

Als die Korrektur-Engine von Overlay B aktiviert war, verkündete ein Screenreader:

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”).

Das Ergebnis ist schlechter als das ursprüngliche Formular ohne Beschriftungen. Vor dem Einblenden des Overlays stieß ein Screenreader-Nutzer auf sieben Felder ohne Beschriftungen – verwirrend, aber zumindest einheitlich. Er konnte anhand der Tabulatorreihenfolge und des Kontexts erraten, welches Feld welches war. Nach dem Einblenden des Overlays stößt der Nutzer auf zwei Felder mit derselben Beschriftung („Name“ sowohl für Vorname als auch für Nachname), zwei Felder mit erfundenen Beschriftungen im Validierungsstil, die nicht mit dem sichtbaren Text übereinstimmen, und drei Felder mit bedeutungslosen, typbasierten Namen. Die unvollständige, falsche Beschriftung ist verwirrender als gar keine Beschriftung, da sie den falschen Eindruck erweckt, das Formular sei barrierefrei gestaltet worden, obwohl wichtige Felder unbeschriftet oder falsch beschriftet bleiben.

Diese Erkenntnis deckt zudem eine Lücke im JSON-Korrekturprotokoll von Overlay B auf. Das JSON enthielt 87 KI-generierte Alt-Text-Einträge und null Einträge zur Formularkorrektur für diese Website. Die Einfügung von Formularbeschriftungen erfolgt vollständig zur Laufzeit über den EmptyControls-Regelhandler – sie ist im konsolidierten Korrektur-JSON nicht sichtbar, wird in keinem Dashboard erfasst, das der Websitebetreiber einsehen kann, und unterliegt keiner manuellen Freigabe. Der Websitebetreiber hat keine Möglichkeit zu erkennen, dass sein Kontaktformular falsch beschriftet ist, es sei denn, er testet es selbst mit einem Screenreader.

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.

Der Nettoeffekt der ADA-Konformität

Das grundlegende Problem besteht darin, dass Overlay-Tools Abdeckung mit Konformität gleichsetzen. Ein Overlay kann auf 1.058 Korrekturregeln verweisen und behaupten, dass es über 40 WCAG-Erfolgskriterien erfüllt. Wenn jedoch 26 % dieser Korrekturen neue Verstöße verursachen – darunter Verstöße der Stufe A, die durch das Ausblenden funktionaler Elemente entstehen –, kann die Nettokonformität schlechter sein als bei der unveränderten Website.

Eine Website ohne Overlay, die 50 Verstöße gegen die WCAG aufweist, befindet sich in einer eindeutigeren rechtlichen Lage als eine Website mit Overlay, die 30 ursprüngliche Verstöße sowie 203 durch das Overlay verursachte Verstöße aufweist – denn die durch das Overlay verursachten Verstöße zeigen, dass der Betreiber der Website ein Tool eingesetzt hat, das Nutzer mit Behinderungen aktiv diskriminiert, was jede Einrede der guten Absicht untergräbt.

Das Fazit