Ich verkaufe selbst ein Overlay. Das vorweg, weil dieser Ratgeber Ihnen ehrlich zeigen soll, wo ein Barrierefreiheits-Overlay helfen kann und wo nicht – und ich Ihnen kein neutraler Beobachter, aber ein offener Praktiker sein will. Die kurze Antwort vorweg: Ein Overlay löst das BFSG-Risiko nicht. Wer Ihnen das verspricht, verkauft Ihnen entweder einen Irrtum oder eine Lüge. In diesem Beitrag erkläre ich Ihnen, was ein Overlay technisch tatsächlich leistet, was es prinzipiell nicht leisten kann, warum die internationale Accessibility-Community geschlossen vor 1-Klick-Lösungen warnt und unter welchen Bedingungen ein Overlay trotzdem einen sinnvollen Platz haben kann.

Was ein Overlay ist und was nicht

Ein Accessibility-Overlay ist ein JavaScript-Widget, das per Codeschnipsel in eine Website eingebunden wird und Nutzern eine kleine Werkzeugleiste anbietet – meist über einen Knopf am Bildschirmrand. Per Klick lassen sich dort UI-Anpassungen wählen wie größere Schriften, kontrastreichere Farben, eine spezielle Schrift für Menschen mit Legasthenie oder ein vergrößerter Mauszeiger. Bekannte Anbieter sind accessiBe, UserWay, EqualWeb und in der DACH-Region etwa Eye-Able. So weit, so harmlos – ein Komfort-Widget. Das Problem entsteht erst dort, wo Anbieter dieses Widget als „Lösung für Barrierefreiheit“ oder gar als „BFSG-konform per Knopfdruck“ verkaufen. Genau das ist es nicht, und es kann es technisch nicht sein.

Was Overlays tatsächlich können

Fairerweise: Ein Overlay kann durchaus nützliche Komfortfunktionen anbieten. Es kann auf Wunsch des Nutzers die Schriftgröße erhöhen, die Zeilenhöhe vergrößern, Linktexte hervorheben, animierte Elemente pausieren, das Farbschema in höheren Kontrast wandeln oder eine Vorlesefunktion für einzelne Absätze starten. Für Nutzer ohne assistive Technologie, die nur ein bisschen mehr Komfort suchen – Ältere mit nachlassendem Sehvermögen, Lesende in greller Umgebung, Menschen mit milder Sehschwäche –, können solche Funktionen den Unterschied zwischen „mühsam“ und „angenehm“ machen. Das ist wertvoll. Es ist nur kein Ersatz für Barrierefreiheit im Sinne der WCAG.

Was Overlays prinzipiell nicht können

Hier wird es technisch. Ein Overlay sitzt im Frontend, also auf der visuellen Schicht. Es kann Pixel manipulieren – aber nicht den Code darunter umschreiben. Das hat Konsequenzen, die kein Marketing-Versprechen wegerklären kann:

• Semantische Strukturen reparieren. Ein div, das wie ein Button aussehen soll, bleibt ein div – ein Overlay macht daraus keinen Button. Screenreader hören weiterhin nur „Klickbar“, nicht „Schaltfläche“.
• Inhaltlich passende Alt-Texte erfinden. Manche Anbieter behaupten, mit KI generierte Alt-Texte zu liefern. In meinen Audits haben diese eine Trefferquote, die ich freundlich „durchwachsen“ nenne. Ein KI-Alt-Text, der „Foto“ oder „Frau mit Tasche“ sagt, beschreibt das Marketing-Banner einer Bank nicht – und ein blinder Nutzer kann mit dieser Information nichts anfangen.
• Tastaturfallen aus Custom-Komponenten lösen. Ein Modal ohne Focus-Trap bleibt eine Tastaturfalle. Ein Cookie-Banner, der den Fokus festhält, bleibt blockiert. Daran ändert kein JavaScript-Widget etwas, weil es die zugrunde liegenden Tastatur-Handler nicht ersetzt.
• Fehlerhafte Formularlabels korrigieren. Wenn ein Feld kein verknüpftes Label hat, hilft kein Overlay – der Screenreader hat keinen Namen für das Feld.
• Live-Region-Logik ergänzen. Wenn ein Suchergebnis dynamisch nachgeladen wird, ohne dass eine Live-Region informiert, hört ein Screenreader-Nutzer nichts. Auch hier liegt die Korrektur im Code, nicht im Frontend-Widget.

Anders gesagt: Alles, was tiefer als das visuelle Erscheinungsbild geht, kann ein Overlay nicht lösen. Und genau dort – im strukturellen Code – sitzt der größere Teil der WCAG-Anforderungen.

Warum die Accessibility-Community Overlays boykottiert

Hier liegt der spannendste und gleichzeitig folgenreichste Punkt. Die internationale Accessibility-Community – Aktivisten, AT-Nutzer, WCAG-Experten – hat sich in einer für die Branche beispiellos breiten Front gegen aggressive Overlay-Werbung positioniert. Im sogenannten Overlay Fact Sheet, einer kollektiven Stellungnahme, haben mehrere hundert Fachleute unterschrieben, dass Overlays die Probleme, die sie zu lösen vorgeben, nicht lösen können. Die Gründe sind dreifach.

Erstens, sie versprechen Konformität, die sie nicht halten können. Etliche Overlay-Anbieter haben für ihre Aussagen rechtliche Auseinandersetzungen mit Verbraucherschutzbehörden zu führen gehabt – die Versprechen erwiesen sich vor Gericht oft als nicht haltbar.

Zweitens, sie verschlechtern für viele AT-Nutzer das Erlebnis aktiv. Wer einen Screenreader benutzt, hat dort längst seine Einstellungen vorgenommen – Sprachstimme, Geschwindigkeit, Lesemodus. Ein Overlay, das versucht, seine eigene Vorlesefunktion über die bestehende AT zu legen, interferiert mit den Werkzeugen, die der Nutzer ohnehin schon optimal eingerichtet hat. Viele blinde Nutzer berichten, dass die ersten Sekunden auf einer Overlay-Seite damit beginnen, das Widget zu schließen, weil es im Weg ist.

Drittens, sie verzögern echte Sanierung. Wer ein Overlay einkauft, denkt häufig, das Thema sei erledigt. Damit wird die eigentliche Code-Arbeit verschoben – und die Compliance-Frage bleibt offen, oft länger, als sie sollte.

Wie unterschiedlich Screenreader auf Code reagieren und warum diese Werkzeuge so empfindlich auf zusätzliche Skripte sind, habe ich in JAWS, NVDA und VoiceOver: Wie echte Nutzer Ihre Website wirklich erleben ausführlich beschrieben.

Wie sich das BFSG-Risiko durch ein Overlay nicht verändert

Der zentrale Punkt für Entscheider. Das Barrierefreiheitsstärkungsgesetz verlangt, dass digitale Produkte und Dienstleistungen den Anforderungen der harmonisierten Norm EN 301 549 entsprechen – also einer Norm, die in weiten Teilen WCAG 2.1 referenziert. Ein Overlay erfüllt diese Anforderungen nicht und kann sie strukturell nicht erfüllen, weil es den Code nicht ändert. Die Marktüberwachung prüft im Beschwerdefall die tatsächliche Konformität der Seite – nicht das Vorhandensein eines Widgets. Wenn die zugrunde liegende Webseite nicht konform ist, ändert auch die schickste Werkzeugleiste an dieser Tatsache nichts.

Schlimmer noch: Wer in seiner Erklärung zur Barrierefreiheit angibt, „mit Overlay XY für Konformität gesorgt zu haben“, produziert eine angreifbare Aussage. Die Erklärung muss wahrheitsgemäß sein, sonst wird sie zur eigenen Belastung im Verfahren. Welche Anforderungen ein wirklich belastbarer Konformitätsnachweis erfüllen muss, lesen Sie in Barrierefreiheit zertifizieren lassen: Was ein belastbarer Nachweis können muss.

Die ehrliche Rolle eines Overlays

Dass ich selbst ein Overlay anbiete – Access Overlay –, ist kein Widerspruch zu allem, was ich Ihnen bisher gezeigt habe. Es ist der Versuch, ein Werkzeug ehrlich in seine Rolle zu stellen. Ein Overlay ist nützlich als Übergangslösung während einer laufenden Sanierung: Wenn Ihre Website noch nicht den Stand erreicht hat, den sie soll, kann ein deklariertes Komfort-Widget Ihren Nutzern zumindest einige Hilfen anbieten, während im Hintergrund am Code gearbeitet wird. Es ist nützlich als Komfort-Tool für die breite Nutzerschaft: Schriftgröße, Kontrast, Animations-Stopp – Dinge, die vielen helfen, ohne dass sie Screenreader-Nutzer sind. Und es ist legitim als Teil einer kombinierten Strategie, in der die echte Arbeit am Code passiert.

Worauf es ankommt: Transparenz. Ein verantwortungsvoll eingesetztes Overlay deklariert ausdrücklich, dass es kein Ersatz für barrierefreie Gestaltung ist, dass es Code-Mängel nicht heilt und dass es nicht den Anspruch erhebt, BFSG-Konformität allein herzustellen. Wer das so kommuniziert, kann ein Overlay einsetzen, ohne sich selbst rechtlich angreifbar zu machen. Wer dagegen das Marketing-Versprechen „Knopfdruck-Konformität“ übernimmt, übernimmt damit auch das Risiko, das dahintersteht.

Wie ein verantwortungsvoller Overlay-Einsatz aussieht

Wenn Sie sich für ein Overlay entscheiden – aus Komfortgründen, als Übergang während Ihrer Sanierungsarbeit, als Teil einer breiteren Strategie –, dann nehmen Sie eines, das mit offenen Karten spielt. Unser Access Overlay ist genau so gebaut: Es bietet die nützlichen UI-Funktionen, die ein modernes Komfort-Widget anbieten kann, und es deklariert in der Konformitäts-Dokumentation transparent, dass es eine Übergangslösung ist, keine vollständige Compliance-Lösung. Es wird in unserer Suite ausdrücklich mit dem Tiefen-Audit Access Ready und dem Monitoring Access Guard kombiniert – das Overlay ist dort, wo die Sanierung noch nicht angekommen ist, das Audit klärt, wo die echte Arbeit liegt, das Monitoring sichert, dass sie nicht verloren geht.

Mein Rat für Ihre Entscheidung: Lassen Sie sich von keinem Anbieter einreden, dass ein Widget Ihr BFSG-Problem löst. Wenn Ihnen jemand „BFSG-Konformität per Knopfdruck“ verspricht, fragen Sie nach dem Audit-Bericht nach EN 301 549, der diese Aussage stützt – Sie werden ihn nicht bekommen. Investieren Sie das Budget in die echte Code-Arbeit, sichern Sie sie mit einem Audit ab, behalten Sie sie mit Monitoring – und nutzen Sie ein transparent deklariertes Overlay nur dort, wo es seine ehrliche Rolle erfüllen kann: als Komfort-Werkzeug, nicht als Compliance-Schild.