Barrierefreiheits-Overlays: Warum Ein-Klick-Lösungen nicht funktionieren

Was sind Barrierefreiheits-Overlays?

Overlays sind JavaScript-Widgets, die per Einzeiler-Code-Snippet auf einer Webseite eingebunden werden und versprechen, die Seite automatisch barrierefrei zu machen. Anbieter wie AccessiBe, UserWay, EqualWeb und AudioEye bieten solche Lösungen an. Sie fuegen typischerweise einen Button (meist ein Rollstuhl-Icon) hinzu, der Optionen wie Schriftgroessenanpassung, Kontrast-Modus und Cursor-Vergroesserung bietet.

Das Versprechen klingt verlockend: Eine Zeile JavaScript einbauen, und die gesamte Webseite ist WCAG-2.1-AA-konform. Kein Entwickler noetig, kein Audit, kein Aufwand. Fuer Betreiber, die ab Juni 2025 unter das Barrierefreiheitsstaerkungsgesetz (BFSG) fallen, wirkt das wie die perfekte Loesung.

Doch die Realitaet sieht anders aus. Ueber 700 Barrierefreiheits-Experten, Behindertenorganisationen und Entwickler haben das Overlay Fact Sheet (overlayfactsheet.com) unterzeichnet — eine gemeinsame Erklaerung, die klar dokumentiert: Automatisierte Overlay-Widgets koennen keine vollstaendige Barrierefreiheit herstellen.

Was Overlays versprechen — und was sie tatsaechlich liefern

Die Marketing-Versprechen der Overlay-Anbieter lassen sich in drei Kategorien unterteilen: Weitere Informationen finden Sie im Overlay-Widgets Glossar.

Versprechen 1: Automatische WCAG-Konformitaet. Overlays behaupten, saemtliche WCAG-2.1-Kriterien automatisch zu erfuellen. In der Praxis koennen sie jedoch nur einen Bruchteil der 50 Erfolgskriterien auf Level AA adressieren. Kriterien wie SC 1.1.1 (Textalternativen), SC 1.3.1 (Info und Beziehungen) oder SC 2.4.6 (Ueberschriften und Labels) erfordern semantisches Verstaendnis des Inhalts, das kein Algorithmus zuverlaessig leisten kann.

Versprechen 2: KI-gesteuerte Alt-Texte. Einige Anbieter wie AccessiBe werben mit KI-generierten Alternativtexten fuer Bilder. Tests zeigen jedoch, dass die generierten Texte haeufig generisch, falsch oder kontextfrei sind. Ein Produktbild erhaelt dann einen Alt-Text wie „Bild eines Objekts" statt „Rotes Sommerkleid in Groesse M". Das erfuellt SC 1.1.1 (Nicht-Text-Inhalt) nicht.

Versprechen 3: Rechtliche Absicherung. Mehrere Anbieter suggerieren, dass ihr Widget vor Klagen schuetzt. Das Gegenteil ist der Fall — Unternehmen mit Overlays werden haeufiger verklagt als solche ohne (siehe Abschnitt „Klagen gegen Overlay-Nutzer").

AccessiBe, UserWay und EqualWeb im Vergleich

AccessiBe ist der bekannteste und zugleich umstrittenste Anbieter. Das Unternehmen investiert stark in Marketing und SEO, wurde aber wiederholt von der Barrierefreiheits-Community kritisiert. Die National Federation of the Blind (NFB) veroeffentlichte 2021 eine Resolution, die AccessiBe explizit als schaedlich bezeichnet. Blinde Nutzer berichteten, dass die AccessiBe-Toolbar ihre JAWS- und NVDA-Konfiguration ueberschrieb.

UserWay positioniert sich als „AI-Powered Accessibility Widget". Das Tool bietet visuelle Anpassungen (Kontrast, Schriftgroesse, Cursor), kann aber strukturelle Probleme wie fehlende Landmarks (SC 1.3.1), falsche Ueberschriftenhierarchie (SC 1.3.1) oder nicht-tastatur-bedienbare Custom-Elemente (SC 2.1.1) nicht beheben.

EqualWeb wirbt mit ISO-27001-Zertifizierung und „100 % Compliance". Unabhaengige Tests zeigen jedoch die gleichen Limitierungen: Das Widget kann keine semantischen Probleme im Quellcode reparieren, keine komplexen Formulare zugaenglich machen und keinen sinnvollen Fokus-Management fuer Single-Page-Applications bereitstellen.

Warum Overlays Screenreader stoeren

Screenreader-Nutzer konfigurieren ihre assistive Technologie individuell — Sprechgeschwindigkeit, Verbositaet, Navigation-Shortcuts. Ein Overlay injiziert eigene ARIA-Attribute und aendert die DOM-Struktur zur Laufzeit. Das fuehrt zu konkreten Problemen:

ARIA-Konflikte: Wenn eine Webseite bereits (korrekte oder fehlerhafte) ARIA-Rollen hat und das Overlay eigene hinzufuegt, entstehen Widersprueche. Ein Element mit role="button" erhaelt ploetzlich ein zusaetzliches aria-label, das den urspruenglichen zugaenglichen Namen ueberschreibt.

Fokus-Stoerungen: Overlays fuegen ein schwebendes Panel in den DOM ein, das die Tab-Reihenfolge veraendert. Tastatur-Nutzer landen ploetzlich im Overlay-Menue statt im Hauptinhalt — ein Verstoss gegen SC 2.4.3 (Fokus-Reihenfolge).

Performance-Einbussen: Das nachgeladene JavaScript (oft 100–300 KB) verlangsamt den Seitenaufbau. Screenreader beginnen mit dem Vorlesen, bevor das Overlay seine Aenderungen angewendet hat — der Nutzer hoert zunaechst die unmodifizierte Version, dann springt die Seite.

Karl Groves, Barrierefreiheits-Experte und Mitgruender von Tenon.io, bringt es auf den Punkt: „Kein Overlay kann die Probleme loesen, die durch schlechte Entwicklung entstanden sind. Man muss den Quellcode reparieren."

Warum Overlays nicht funktionieren

Die Barrierefreiheits-Community und Experten lehnen Overlays aus mehreren grundlegenden Gruenden ab:

Sie koennen fehlende Alt-Texte nicht zuverlaessig erraten. Ein Algorithmus weiss nicht, ob ein Bild dekorativ ist oder eine wichtige Information traegt. WCAG SC 1.1.1 verlangt bedeutungsvolle Textalternativen — das erfordert menschliches Urteil.

Sie koennen keine kaputte Tastatur-Navigation reparieren. Wenn ein Custom-Dropdown mit <div> statt <select> gebaut ist und keine Keyboard-Events hat, kann kein Overlay das nachtraeglich reparieren (SC 2.1.1 Tastatur).

Sie koennen keine semantische Struktur herstellen. Fehlende oder falsche Ueberschriftenhierarchien, fehlende Landmarks, falsche Tabellenstrukturen — all das sitzt im HTML-Quellcode und kann nur dort behoben werden (SC 1.3.1 Info und Beziehungen).

Sie ueberlagern manchmal den eigentlichen Inhalt. Das Overlay-Panel kann Inhalte verdecken, besonders auf mobilen Geraeten. Das erzeugt neue Barrierefreiheits-Probleme statt bestehende zu loesen.

Zusammengefasst: WCAG 2.1 hat 50 Erfolgskriterien auf Level AA. Overlays adressieren bestenfalls 5–10 davon — und selbst diese nur oberflaechlich. Die restlichen 40+ Kriterien erfordern Aenderungen am Quellcode.

Klagen gegen Overlay-Nutzer: Die Datenlage

In den USA, wo der Americans with Disabilities Act (ADA) bereits seit 1990 digitale Barrierefreiheit fuer bestimmte Unternehmen fordert, gibt es eine klare Datenlage zu Overlay-Klagen:

Hunderte Klagen trotz Overlay: Laut UsableNet wurden allein 2023 ueber 400 ADA-Klagen gegen Webseiten eingereicht, die ein Overlay nutzten. Der Einsatz eines Overlays schuetzt also nachweislich nicht vor Klagen — im Gegenteil, manche Kanzleien suchen gezielt nach Overlay-Icons, weil sie wissen, dass die zugrunde liegenden Probleme nicht geloest sind.

Gerichtsurteile: In Faellen wie Robles v. Domino's Pizza und Gil v. Winn-Dixie haben US-Gerichte bestaetigt, dass technische Hilfsmittel allein nicht ausreichen — die Webseite selbst muss zugaenglich sein. AccessiBe-Kunden wie Eyebobs und Murphy Oil wurden trotz aktivem Overlay verklagt und verloren.

Europaeische Perspektive: BFSG und European Accessibility Act

In Europa ist die Durchsetzung noch im Aufbau, aber die rechtliche Grundlage ist klar:

Das BFSG (§ 3 Abs. 1) verweist auf die harmonisierte Norm EN 301 549, die wiederum WCAG 2.1 Level AA als technischen Standard referenziert. Die Anforderung ist eindeutig: Produkte und Dienstleistungen muessen selbst barrierefrei gestaltet sein. Ein Overlay, das lediglich eine visuelle Schicht ueber eine nicht-konforme Webseite legt, erfuellt diese Anforderung nicht.

§ 37 BFSG (Marktaufsicht) gibt den zustaendigen Marktaufsichtsbehoerden das Recht, die Konformitaet zu pruefen. Dabei wird der tatsaechliche Quellcode und die Nutzbarkeit mit assistiver Technologie bewertet — nicht, ob ein Widget-Button auf der Seite existiert.

Der European Accessibility Act (EAA) bildet den EU-weiten Rahmen, den das BFSG in deutsches Recht umsetzt. Auch hier ist die Intention klar: nachhaltige, eingebaute Barrierefreiheit statt nachtraeglicher Kosmetik.

Abmahnungen nach § 8 UWG wegen irrefuehrender Barrierefreiheits-Behauptungen sind ebenfalls denkbar — wenn ein Unternehmen „barrierefrei" kommuniziert, aber nur ein Overlay einsetzt, koennte das als wettbewerbswidrig eingestuft werden.

WCAG kann nicht per JavaScript-Overlay geloest werden

Ein grundlegendes Missverstaendnis: Barrierefreiheit ist keine Darstellungs-Eigenschaft, die man per CSS oder JavaScript umschalten kann. Sie ist eine Eigenschaft der Informationsarchitektur.

Konkrete Beispiele fuer WCAG-Kriterien, die kein Overlay loesen kann:

SC 1.3.1 — Info und Beziehungen: Wenn eine Datentabelle als verschachtelte <div>-Elemente gebaut ist, kann kein Overlay die semantische Tabellenstruktur nachtraeglich erzeugen.

SC 2.1.1 — Tastatur: Ein Custom-Slider ohne Keyboard-Events kann nicht durch ein Overlay tastatur-bedienbar gemacht werden. Das erfordert Aenderungen am JavaScript des Sliders selbst.

SC 4.1.2 — Name, Rolle, Wert: Wenn ein Custom-Formularfeld keinen zugaenglichen Namen hat, muesste das Overlay erraten, welches Label zu welchem Feld gehoert — bei komplexen Formularen scheitert das regelmaessig.

SC 2.4.1 — Bloecke umgehen: Skip-Links muessen im HTML-Quellcode verankert sein. Ein nachtraeglich injizierter Skip-Link kann Konflikte mit dem bestehenden Fokus-Management verursachen.

Die Schlussfolgerung ist eindeutig: Echte Barrierefreiheit erfordert Aenderungen am Quellcode — an HTML-Struktur, CSS und JavaScript der Webseite selbst.

Die Overlay-Geschaeftsmodelle: Warum Anbieter trotzdem werben

Warum investieren AccessiBe, UserWay und andere Millionen in Marketing, obwohl die Fachwelt ihre Produkte ablehnt? Die Antwort liegt im Geschaeftsmodell:

Wiederkehrende Einnahmen: Overlays werden als SaaS-Abo verkauft (300–500 EUR/Jahr pro Domain). Fuer den Anbieter ist das ein planbarer Umsatzstrom. Fuer den Kunden bedeutet es: Sobald das Abo endet, verschwindet auch die (ohnehin unzureichende) Anpassung.

Niedrige Einstiegshuerde: Eine Zeile JavaScript kopieren ist deutlich einfacher als sich mit WCAG-Kriterien auseinanderzusetzen. Das spricht Betreiber an, die das BFSG als laestige Pflicht empfinden und eine schnelle Loesung suchen.

Angst-Marketing: Viele Overlay-Anbieter nutzen die Angst vor Abmahnungen und Bussgeldern als Verkaufsargument. Dabei verschweigen sie, dass ihr Produkt genau davor nicht schuetzt — im Gegenteil.

AccessiBe hat nach massiver Kritik 2021 seine Marketing-Strategie angepasst und bezeichnet sich nun als „Ergaenzung" statt als vollstaendige Loesung. An der technischen Limitierung aendert das nichts.

Die Alternative: Echte Barrierefreiheit umsetzen

Statt Geld fuer ein Overlay-Abo auszugeben, solltest du in die tatsaechliche Barrierefreiheit deiner Webseite investieren. Der Weg dorthin ist planbarer als viele denken:

Schritt 1 — Ist-Zustand ermitteln: Nutze einen BFSG-Scanner, um die haeufigsten Barrierefreiheits-Probleme zu identifizieren. Ergaenze das durch einen manuellen Audit mit Tastatur und Screenreader.

Schritt 2 — Low-Hanging-Fruits beheben: Die meisten Webseiten haben 5–10 wiederkehrende Fehlertypen: fehlende Alt-Texte, zu geringe Kontraste (unter 4.5:1), fehlende Formular-Labels, fehlende Dokumentsprache. Diese lassen sich oft in wenigen Stunden beheben.

Schritt 3 — Strukturelle Probleme angehen: Tastatur-Navigation, Fokus-Management, korrektes ARIA, logische Ueberschriftenhierarchie. Hier hilft ein Entwickler mit Barrierefreiheits-Erfahrung.

Schritt 4 — Testen mit echten Nutzern: Teste mit einem Screenreader (NVDA ist kostenlos), mit reiner Tastatur-Navigation und mit verschiedenen Zoom-Stufen.

Kosten-Vergleich: Ein Overlay-Abo kostet 300–500 EUR pro Jahr — und loest kein einziges Problem wirklich. Ein professionelles Audit mit Behebung der haeufigsten Fehler kostet einmalig 1.000–5.000 EUR, je nach Umfang der Webseite. Dafuer erhaeltst du eine nachhaltig barrierefreie Webseite, die dem BFSG und der EN 301 549 tatsaechlich entspricht.

Langfristiger Nutzen: Eine nativ barrierefreie Webseite profitiert auch in anderen Bereichen: Bessere SEO-Performance (Google bewertet semantisches HTML positiv), schnellere Ladezeiten (kein zusaetzliches Widget-JavaScript), breitere Zielgruppe (15 % der Bevoelkerung leben mit einer Behinderung) und Zukunftssicherheit, wenn die EN 301 549 oder die WCAG-Richtlinien aktualisiert werden.

Checkliste: Overlay erkennen und ersetzen

Wenn du bereits ein Overlay im Einsatz hast, folge dieser Checkliste:

1. Overlay identifizieren: Suche in deinem HTML-Quellcode nach Einbindungen von accessibe.com, userway.org, equalweb.com, audioeye.com oder aehnlichen Domains. Haeufig findest du ein <script>-Tag im <head> oder vor </body>.

2. Ist-Zustand dokumentieren: Fuehre vor dem Entfernen einen vollstaendigen BFSG-Scan durch und speichere das Ergebnis.

3. Overlay-Script entfernen: Loesche das Script-Tag und teste die Seite gruendlich — manchmal hinterlassen Overlays CSS-Reste oder Cookie-Eintraege.

4. Echte Barrierefreiheit umsetzen: Arbeite die Scan-Ergebnisse Punkt fuer Punkt ab. Beginne mit den kritischsten Verstoessen (fehlende Alt-Texte, unzureichende Kontraste, fehlende Labels).

5. Ergebnis pruefen: Fuehre nach der Behebung einen erneuten Scan durch und vergleiche mit dem Vorher-Ergebnis. Teste zusaetzlich manuell mit Tastatur und Screenreader.

Dieser Artikel ersetzt keine Rechtsberatung. Bei konkreten rechtlichen Fragen zur BFSG-Konformitaet wende dich an einen spezialisierten Anwalt.

Häufig gestellte Fragen