"Unsere Website ist zu 100% WCAG-konform — wir haben accessiBe." Diese Aussage hört man von Unternehmen, die in guter Absicht ein Overlay-Widget eingekauft haben. Das Problem: Sie stimmt nicht. Accessibility Overlays schaffen keine echte Barrierefreiheit — und können sogar schaden.
Wichtig: Overlay-Anbieter vermarkten ihre Produkte aggressiv mit Versprechen wie "sofortige WCAG-Konformität" oder "automatische Barrierefreiheit". Diese Versprechen sind technisch nicht haltbar — und können zu falscher Sicherheit führen.
Was sind Accessibility Overlays?
Accessibility Overlays sind JavaScript-Widgets, die als externer Code in eine Website eingebunden werden. Sie erscheinen meist als kleiner Button (oft mit Rollstuhl-Symbol oder Personen-Symbol) und bieten beim Klicken eine Seitenleiste mit Einstellungen:
- Schriftgröße ändern
- Kontrast erhöhen
- "Lesemodus" aktivieren
- Animations stoppen
- Cursor-Größe ändern
Bekannte Anbieter sind accessiBe, UserWay, AudioEye, Monsido, EqualWeb und Recite Me. Preise liegen zwischen 50–500 €/Monat.
Warum Overlays keine WCAG-Konformität schaffen
Das zentrale Problem ist technischer Natur: JavaScript kann auf eine fertig gerenderte Seite aufgesetzt werden, aber keine strukturellen Probleme im HTML rückwirkend beheben.
Problem 1: Fehlende Alt-Texte
accessiBe und Co. nutzen KI, um Alt-Texte automatisch zu generieren. Die Qualität dieser KI-generierten Alt-Texte ist oft schlecht — unspezifisch, falsch oder irreführend. WCAG 1.1.1 fordert sinnvolle Textalternativen, keine beliebigen Beschreibungen.
Problem 2: Tastaturnavigation
Wenn custom JavaScript-Komponenten (Dropdown-Menüs, Modals, Sliders) nicht per Tastatur bedienbar sind, kann ein nachträgliches Overlay das nicht reparieren. Die fehlende Tastaturlogik ist im Widget-Code verankert, nicht durch CSS oder ARIA patchbar.
Problem 3: Kontrast
Manche Overlays bieten einen "Hochkontrast-Modus". Das Problem: Dieser Modus ist nicht standardmäßig aktiv. Nutzer müssen ihn erst finden und aktivieren. Wer ihn nicht aktiviert, sieht weiterhin zu wenig Kontrast. WCAG fordert ausreichenden Kontrast als Standard.
Problem 4: Screen Reader-Interaktion
Manche Overlays interferieren negativ mit Screen Readern — weil das Widget selbst ARIA-Attribute falsch setzt oder den DOM so manipuliert, dass bestehende Zugänglichkeit verschlechtert wird.
Was echte Nutzer sagen
Über 800 Disability-Rights-Organisationen und Accessibility-Experten weltweit haben das "Overlay Fact Sheet" (overlayfactsheet.com) unterzeichnet — eine Erklärung, die Overlays klar ablehnt. Zitat:
"We hereby call on the vendors of overlay products to stop making false claims about the effectiveness of their products."
Blind-Organisationen berichten, dass accessiBe und ähnliche Produkte ihre Erfahrung auf Websites oft verschlechtern — weil das Widget den Screen Reader stört oder Inhalte falsch auszeichnet.
Das rechtliche Risiko: Schein-Compliance
Wer ein Overlay einsetzt und glaubt, damit BFSG-konform zu sein, befindet sich in einer gefährlichen Situation:
- Das BFSG fordert technische Konformität mit EN 301 549 / WCAG 2.1 AA — nicht das Vorhandensein eines Widgets.
- Bei einer Prüfung durch Marktüberwachungsbehörden wird der tatsächliche Code geprüft — nicht ob ein Overlay vorhanden ist.
- Falsche Konformitätserklärungen sind nach § 31 BFSG ein eigenständiger Bußgeldtatbestand (bis 100.000 €).
- In den USA wurden mehrere Klagen (ADA-Title-III) gegen Unternehmen gewonnen, die accessiBe nutzten — weil ihre Websites trotzdem nicht zugänglich waren.
Was wirklich hilft
Echte Barrierefreiheit entsteht durch Code — nicht durch Widgets:
Wirksame Maßnahmen
- ✓ Alt-Texte für alle Bilder schreiben
- ✓ Semantisches HTML (Überschriften, Listen, Landmark)
- ✓ ARIA-Attribute wo nötig
- ✓ Tastaturnavigation testen und sicherstellen
- ✓ Kontraste von Anfang an einhalten
- ✓ Formulare mit Labels versehen
Nicht wirksam
- ✗ Overlay-Widgets als alleinige Lösung
- ✗ Automatische KI-Alt-Texte ohne Qualitätsprüfung
- ✗ "Hochkontrast-Modus" statt korrektem Kontrast
- ✗ JavaScript-Patches für strukturelle HTML-Probleme
Der richtige Ansatz
- Ist-Zustand ermitteln: Automatisierten Scan durchführen. Wissen, was konkret nicht funktioniert.
- Prioritäten setzen: Tastaturnavigation und Alt-Texte zuerst — größte Wirkung für die meisten Nutzer.
- Code-Fixes implementieren: Im echten Code, nicht per Widget.
- Regelmäßig nachprüfen: Barrierefreiheit ist kein einmaliges Projekt, sondern kontinuierliche Qualitätssicherung.
Mehr zur praktischen Umsetzung finden Sie in unserer Schritt-für-Schritt-Anleitung für barrierefreie Websites.
Echte Code-Level-Analyse statt Overlay
Unser Scanner analysiert Ihren echten HTML-Code auf WCAG-Verstöße — ohne Widget, ohne Versprechen, die er nicht halten kann. Kostenlos, ehrlich, direkt.
Website ehrlich analysieren →