Das Overlay-Problem: Warum ein Widget Sie nicht vor einer BFSG-Abmahnung schützt

Rechtlich und technisch funktioniert das so nicht. Seit die Marktüberwachungsstelle der Länder für Barrierefreiheit Anfang 2026 in die aktive Kontrollphase gegangen ist, geraten genau solche Schnelllösungen in den Fokus. Wer sich allein auf ein Overlay verlässt, riskiert trotzdem eine Abmahnung, denn Behörden und Gerichte schauen inzwischen genauer hin.

Was ein Accessibility-Overlay eigentlich ist

Ein Overlay ist ein zusätzliches Skript, das Anbieter meist mit einer einzigen Codezeile in eine bestehende Website einbinden. Es blendet ein Bedienmenü ein, über das Nutzende Kontrast, Schriftgröße oder Abstände anpassen können, teilweise ergänzt um automatisch generierte Alt-Texte oder nachträglich eingefügte ARIA-Label. Beworben wird das häufig als vollständige Lösung, die ohne Eingriff in den Quellcode auskommt und innerhalb weniger Minuten einsatzbereit ist.

Genau dieses Versprechen ist das Problem. Ein Skript, das über eine fertige Seite gelegt wird, kann viele strukturelle Ursachen von Barrieren nicht erreichen, weil es den zugrunde liegenden Code nicht ändert, sondern nur zur Laufzeit im Browser eingreift.

Angesichts der steigenden Kontrolldichte durch das BFSG ist die Nachfrage nach solchen Sofortlösungen zuletzt spürbar gewachsen. Gerade Unternehmen unter Zeitdruck greifen zu einem Overlay, weil es günstiger und schneller wirkt als eine vollständige Umsetzung, ohne zu wissen, dass sie damit rechtlich weiterhin ungeschützt bleiben.

Warum Overlays technisch an ihre Grenzen stoßen

Fehlende Formularetiketten, eine unlogische Fokusreihenfolge, nicht per Tastatur erreichbare Menüs oder eine falsche Überschriftenhierarchie liegen im Markup selbst begründet. Ein nachträglich eingebundenes Skript kann solche Probleme bestenfalls überdecken, nicht beheben. In der Praxis zeigen sich zudem neue Barrieren: Overlays greifen oft in das Verhalten von Screenreadern ein und überschreiben damit individuelle Einstellungen, die Nutzende mit Behinderung sich bewusst eingerichtet haben.

• ✓ Werbeversprechen wie "in Minuten barrierefrei", ohne dass zuvor eine Analyse der Website stattgefunden hat
• ✓ Kein Zugriff auf den Quellcode nötig, das gesamte Versprechen basiert auf einer einzigen Codezeile
• ✓ Keine Erwähnung manueller Tests mit Tastatur, Screenreader oder Vergrößerungssoftware
• ✓ Keine sichtbare Historie von Korrekturen im Code, sondern nur laufende Anpassungen im Skript selbst

Ein Beispiel aus der Praxis

Ein Onlineshop bindet ein Overlay ein und bewirbt seine Website danach als barrierefrei. Das Kontrastmenü funktioniert, Nutzende können die Schrift vergrößern, ein automatisch generierter Alt-Text erscheint bei den Produktbildern. Im Bestellprozess bleibt der Button "In den Warenkorb" trotzdem nur per Maus erreichbar, weil er technisch kein echtes button-Element ist, sondern ein per JavaScript gestyltes div ohne Tastaturfokus. Das Overlay kann diese Lücke nicht schließen, weil es die HTML-Struktur des Elements nicht verändert, sondern nur eine zusätzliche Bedienoberfläche daneben legt.

Für Screenreader-Nutzende ändert sich dadurch nichts, der zentrale Kaufabschluss bleibt unzugänglich. Genau solche Lücken in geschäftskritischen Nutzungswegen sind es, die bei einer Prüfung durch die Marktüberwachungsstelle oder in einer Abmahnung auffallen, unabhängig davon, wie viele Komfortfunktionen ein Overlay zusätzlich anbietet.

Der Fall accessiBe, ein Warnsignal auch für Deutschland

Wie ernst das Problem inzwischen genommen wird, zeigt ein Fall aus den USA. Die US-Handelsaufsicht FTC ordnete im Januar 2025 an, dass der Overlay-Anbieter accessiBe eine Million US-Dollar zahlen muss. Der Vorwurf: Das Unternehmen hatte behauptet, sein KI-gestütztes Tool mache jede Website automatisch WCAG-konform, was laut FTC nicht der Wahrheit entsprach. Zusätzlich hatte accessiBe bezahlte Kundenbewertungen veröffentlicht, ohne die geschäftliche Verbindung zu den Rezensenten offenzulegen.

Nach einer Analyse von US-Gerichtsdaten durch das Unternehmen TestParty wurden allein 2023 und 2024 mehr als 800 Unternehmen verklagt, die zuvor ein Overlay-Widget wie accessiBe, UserWay oder EqualWeb installiert hatten, das entspricht über 25 Prozent aller in diesem Zeitraum erfassten Klagen im Bereich digitaler Barrierefreiheit. Das ist ein US-amerikanischer Kontext mit eigenem Rechtssystem, das Muster dahinter lässt sich aber nicht ignorieren: Ein installiertes Widget hat in keinem dieser Fälle vor einer Klage geschützt.

Rechtlich reicht ein Widget in Deutschland nicht aus

Das Barrierefreiheitsstärkungsgesetz verlangt, dass Websites und Onlineshops die Barrierefreiheitsanforderungen tatsächlich erfüllen. Als technischer Maßstab dient dabei die harmonisierte Norm EN 301 549, die inhaltlich auf den WCAG-2.2-Erfolgskriterien für Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit aufbaut. Diese Kriterien lassen sich nicht durch ein einzelnes Skript erfüllen, sie verlangen strukturelle Änderungen am Code und in vielen Fällen manuelle Tests, die kein automatisiertes Werkzeug vollständig ersetzt.

Die Marktüberwachungsstelle der Länder für Barrierefreiheit ist seit Januar 2026 in der aktiven Kontrollphase, mit Fokus auf reichweitenstarke Angebote und Anbieter mit negativer Mängel-Historie. Geprüft werden dabei ganze Nutzungswege wie ein vollständiger Bestellprozess, nicht nur einzelne Buttons oder Bilder. Seit Februar 2026 kursieren zudem professionelle Abmahnschreiben mit durchschnittlich rund 2.700 Euro brutto Kosten pro Schreiben, Bußgelder der Behörden können je nach Fall bis zu 100.000 Euro betragen. Ein Overlay, das lediglich Symptome kaschiert, ändert an dieser Risikolage nichts.

Auch die EU-Ebene setzt Deutschland unter Druck: Im März 2026 hat die EU-Kommission eine Stellungnahme mit Gründen wegen unzureichender Umsetzung der zugrunde liegenden EU-Richtlinie 2019/882 übermittelt, bei ausbleibender Nachbesserung droht ein Verfahren vor dem Europäischen Gerichtshof. Für Unternehmen bedeutet das, dass die Kontrolldichte eher zu- als abnimmt, ein Zustand, den kein Overlay abfedern kann.

Was wirklich zählt: Analyse, Umsetzung, Monitoring

Wirksame Barrierefreiheit entsteht nicht durch ein zusätzliches Skript, sondern durch einen vollständigen Workflow. Auch verbreitete Mythen rund um Barrierefreiheit halten sich hartnäckig, die Vorstellung, ein Widget reiche aus, gehört dazu.

• ✓ Analyse, eine Kombination aus automatisiertem Scan und manuellen Tests deckt häufige Barrieren auf, die Werkzeuge allein übersehen
• ✓ Umsetzung, gefundene Probleme werden im Code behoben, nicht nur im Browser überdeckt
• ✓ Monitoring, neue Inhalte und Funktionen werden laufend erneut geprüft, weil sich Websites ständig verändern
• ✓ Dokumentation, eine korrekt gepflegte Barrierefreiheitserklärung macht den Stand der Umsetzung rechtssicher nachvollziehbar

Wie SiteCockpit unterstützt

SiteCockpit trennt bewusst zwischen echter Umsetzung und Nutzerkomfort. easyMonitoring scannt Websites kontinuierlich, erkennt Barrieren und priorisiert sie nach Dringlichkeit, sodass Ihr Team strukturiert an den tatsächlichen Ursachen arbeiten kann. Wo automatisierte Scans an ihre Grenzen stoßen, etwa bei komplexen Interaktionen oder der tatsächlichen Bedienbarkeit mit einem Screenreader, ergänzen die manuellen Audits von SiteCockpit die Prüfung durch menschliche Fachleute.

Das Frontend-Widget easyVision ist bewusst kein Ersatz für diesen Workflow. Es bietet Nutzenden zusätzliche, freiwillige Anpassungsmöglichkeiten wie Kontrast, Schriftgröße oder einen Fokus-Modus, während die strukturelle Barrierefreiheit im Hintergrund über Analyse und Umsetzung entsteht. Den aktuellen Stand dieser Umsetzung dokumentiert easyStatement automatisch in einer rechtssicheren Barrierefreiheitserklärung.

Der Unterschied zu einem reinen Overlay liegt im Ansatz: Statt ein Symptom im Browser zu überdecken, arbeitet SiteCockpit an der Ursache im Code und hält den Fortschritt laufend nachvollziehbar fest. Für Unternehmen, die bereits ein Overlay im Einsatz haben, lohnt sich deshalb kein Austausch, sondern eine Ergänzung: ein vollständiger Scan zeigt innerhalb weniger Minuten, welche strukturellen Lücken hinter der Komfortoberfläche noch offen sind.

Ein Overlay kann ein sinnvoller Baustein für den Nutzerkomfort sein, als alleinige Antwort auf das BFSG hält es weder der rechtlichen Prüfung noch der technischen Realität stand. Wer auf Nummer sicher gehen will, kombiniert automatisiertes Monitoring wie easyMonitoring mit echter Umsetzung im Code.