Overlays für Barrierefreiheit: der Einzeiler-Fix, der Ihnen eine Klage einbringt

Kurz gesagt: nein. Ein Barrierefreiheits-Overlay, also das Skript, das einer bestehenden Website ein Widget hinzufügt, macht diese nicht konform. Unabhängige Tests zeigen, dass Overlays nur einen Bruchteil der WCAG-Probleme erfassen, dass ein wachsender Anteil der Barrierefreiheitsklagen sich gegen Websites richtet, auf denen bereits eines installiert ist, und dass die FTC bereits einen großen Overlay-Anbieter mit einer Geldstrafe belegt hat, weil er das Gegenteil behauptete. Echte Konformität wird in die Komponenten eingebaut, nicht nachträglich aufgesetzt.

Was ist ein Barrierefreiheits-Overlay und warum wird es als Lösung verkauft?

Ein Overlay ist ein einzelnes <script>-Tag, das ein Anbieter als Abkürzung zur Konformität verkauft. Einmal installiert, fügt es ein schwebendes Widget mit Reglern für Schriftgröße und Kontrast sowie einen Schalter für „Animationen pausieren“ hinzu und führt automatisierte Skripte aus, die versuchen, die Seite im laufenden Betrieb zu flicken: Alt-Texte werden erraten, Farbwerte angepasst, ARIA-Attribute umgeschrieben, die es selbst nicht verfasst hat.

Das Verkaufsargument ist wirklich verlockend: keine Code-Review, keine Designer-Zeit, und ein Badge, das die Website als geschützt ausweist. Was dabei ausgeklammert bleibt, ist der entscheidende Punkt: Das Widget rät bei einer Website, die es nicht selbst gebaut hat, auf einer Seite, die es nicht vollständig erfassen kann.

Wie viel von WCAG kann ein Overlay tatsächlich erkennen?

Nicht den größten Teil. Automatisierte Werkzeuge, einschließlich der Scanner in Overlay-Widgets, können allein nur eine Minderheit der WCAG-Erfolgskriterien sinnvoll prüfen.

(Deque, Deque coverage report, zur erneuten Prüfung.)

Diese Lücke ist struktureller Natur, kein Fehler, den das nächste Update behebt. Ein Skript kann bestätigen, dass ein Bild ein alt-Attribut besitzt. Es kann jedoch nicht beurteilen, ob dieser Text das Bild tatsächlich beschreibt, ob ein individuell erstelltes Widget auf die Tastatur reagiert, oder ob die Lesereihenfolge für einen Screenreader sinnvoll ist. Das sind Ermessensfragen, und genau daran fehlt es einem Overlay. Die WebAIM Million, ein jährlicher Scan von einer Million Startseiten, fand 2026 weiterhin auf 95,9 Prozent davon feststellbare WCAG-2-Verstöße, ein Anstieg gegenüber 94,8 Prozent im Vorjahr (WebAIM, zur erneuten Prüfung). Automatisierte Erkennung allein schließt diese Lücke nicht. Sie wird größer.

Werden Overlays in Barrierefreiheitsklagen tatsächlich namentlich genannt?

Ja, und der Trend spricht nicht für das Widget. UsableNets Klagereport für 2024 stellte fest, dass sich rund ein Viertel aller in jenem Jahr eingereichten digitalen Barrierefreiheitsklagen gegen Websites richtete, auf denen bereits ein Overlay installiert war, wobei das Overlay selbst als Barriere angeführt wurde und nicht als Lösung (berichtet über eine Sekundärquelle zu UsableNets Daten, Accessibility.Works, zur erneuten Prüfung). UsableNets eigenes Monitoring für 2025 zeigt, dass sich dieses Muster fortsetzt: Klagen, die Barrierefreiheits-Widgets erwähnen, wurden jeden Monat verzeichnet, 85 im Januar, ansteigend auf 132 im Februar, danach eingependelt zwischen 99 und 119 pro Monat bis Juni (UsableNet, zur erneuten Prüfung).

Dass ein Widget vorhanden ist, beweist weder, dass es die Klage verursacht hat, noch, dass Websites ohne ein solches Widget sicherer sind. Über zwei Jahre der Beobachtung hinweg hat sich ein Overlay nicht als glaubwürdiger Ersatz für die Behebung des zugrunde liegenden Codes erwiesen. Kanzleien auf Klägerseite testen daran vorbei, und Gerichte haben es nicht als Schutzschild anerkannt.

Was ist bei der FTC und accessiBe passiert?

Dies ist der Fall, durch den „Overlays funktionieren eigentlich nicht“ von einer Beschwerde der Community zu geltendem Bundesrecht wurde. Im Januar 2025 kündigte die Federal Trade Commission eine Beschwerde und einen Vergleichsvorschlag gegen accessiBe an, einen der bekanntesten Overlay-Anbieter, der am 21. April 2025 als Verfügung rechtskräftig wurde. Der Vorwurf: accessiBes accessWidget sei damit beworben worden, mithilfe von KI jede Website WCAG-konform machen zu können. Das war falsch: Es behob grundlegende Komponenten wie Navigationsmenüs, Formularfelder und Bildbeschreibungen nicht. Die Beschwerde besagte zudem, accessiBe habe Empfehlungen Dritter so aufbereitet, dass sie unabhängig wirkten, ohne die eigene Beteiligung offenzulegen. Das Unternehmen zahlte 1 Million US-Dollar und darf ohne Nachweis nicht mehr behaupten, sein Produkt könne eine Website WCAG-konform machen oder sie dauerhaft konform halten (FTC, zur erneuten Prüfung).

Das ist einer der größten Anbieter dieser Kategorie, dem eine Regulierungsbehörde nachgewiesen hat, die Möglichkeiten der Kategorie übertrieben dargestellt zu haben. Das ist als Obergrenze dessen zu verstehen, was ein Overlay ehrlicherweise versprechen kann, nicht als Untergrenze.

Was funktioniert stattdessen tatsächlich?

Es gibt keine Abkürzung. Die Lösung ist dieselbe Disziplin, die eine Website auch in jeder anderen Hinsicht gut macht.

1. Bei der Komponente ansetzen, nicht bei der Seite. Jeder Button, jedes Formularfeld, jedes Menü und jedes Modal wird von Anfang an mit korrektem semantischem HTML und ARIA gebaut, nicht nachträglich geflickt.
2. Tastaturnavigation zu einem vollwertigen Pfad machen. Eine Funktion, die nur mit der Maus funktioniert, ist nicht fertig, unabhängig von ihrer Bewertung.
3. Mit echter assistiver Technologie testen. Ein Screenreader, ein Durchgang nur mit Tastatur und eine Person, die täglich auf diese Technologie angewiesen ist, erkennen, was ein Scanner nicht kann.
4. Kontrast und Bewegung am Standard messen, nicht am Augenmaß. Die Kontrastverhältnisse nach WCAG 2.2 AA und die Unterstützung von prefers-reduced-motion werden geprüft, nicht vorausgesetzt.
5. Nach jeder Änderung erneut testen. Konformität ist eine Eigenschaft des aktuellen Builds, kein einmalig erworbenes Zertifikat.

Deshalb behandelt Thabrew Effect Barrierefreiheit als Teil desselben Systems wie Sichtbarkeit und Konversion, niemals als Posten, der an ein Plugin delegiert wird. Eine Komponente, die von Anfang an barrierefrei gebaut wird, dient jedem Besucher und jedem Audit zugleich. Ein nachträglich aufgesetztes Widget dient einem Screenshot.

Ein klarer Hinweis vor den FAQ: Nichts davon ist Rechtsberatung. Dieser Artikel fasst öffentlich berichtete Forschung und eine bundesbehördliche Durchsetzungsmaßnahme zusammen. Wer mit einer aktiven Barrierefreiheitsbeschwerde konfrontiert ist, braucht einen Anwalt, keinen Blogbeitrag.