Wer sich mit digitaler Barrierefreiheit beschäftigt, begegnet ihnen früher oder später: Accessibility Overlays. Kleine JavaScript-Widgets, die man mit einem einzigen Code-Schnipsel in die eigene Website einbindet und die anschließend versprechen, die Seite barrierefrei zu machen. Automatisch. Ohne echte Entwicklungsarbeit. Ohne Konzept. Ohne Aufwand.

Klingt gut. Ist es aber nicht.

Was Overlays versprechen – und was sie tatsächlich tun

Die Versprechen der Anbieter sind groß: WCAG-Konformität, BITV-Compliance, rechtliche Absicherung. Nutzerinnen und Nutzern werden Schalter für Textvergrößerung, Kontrastverstärkung, vereinfachte Darstellung oder Graustufenmodus angeboten. Das Widget erscheint als Button am Seitenrand, ein Klick öffnet ein Panel mit Einstellungsmöglichkeiten.

Das klingt nach echter Hilfe. In der Praxis ist es das selten.

Overlays arbeiten mit nachträglichen Korrekturen: Sie versuchen, Fehler im bestehenden HTML und CSS automatisch zu beheben – fehlende Alt-Texte erraten, Farbkontraste durch CSS-Überschreibungen anpassen, Fokus-Styles nachrüsten. Das Problem: Wer echte strukturelle Barrierefreiheitsprobleme hat, braucht keine Politur obendrauf. Er braucht saubere Grundlagen.

Automatisierte Werkzeuge können bestenfalls 30 bis 40 Prozent aller WCAG-Kriterien überhaupt prüfen – geschweige denn beheben. Was ein Overlay „repariert”, ist häufig oberflächlich. Was wirklich zählt – semantisch korrekte Struktur, logische Reihenfolge, sinnvolle Labels, robuste Interaktionsmuster – bleibt unangetastet.

Was die Forschung zeigt: Daniela Kubeschs Masterarbeit

Wer über Overlays diskutiert, kommt an einer Arbeit nicht vorbei: „The Impact of Web Accessibility Overlays on the Usability and User Experience for People with Permanent Visual Impairments” (öffnet in neuem Tab) von Daniela Kubesch, 2024 veröffentlicht als Double-Degree-Masterarbeit zwischen der FH Salzburg und der Halmstad University. Die Arbeit ist öffentlich zugänglich, methodisch solide und ich empfehle sie uneingeschränkt.

Kubesch hat 21 Personen mit dauerhaften Sehbeeinträchtigungen durch realistische Aufgaben auf Websites geführt – mit und ohne Overlay. Gleichzeitig hat sie die Overlays technisch gegen WCAG 2.1 evaluiert und Interviews mit Accessibility-Consultants sowie mit Vertreterinnen und Vertretern von Overlay-Anbietern geführt. Das Ergebnis ist nicht überraschend, aber gut belegt: Die Overlays konnten die tatsächliche Bedienbarkeit nicht verbessern. Die technischen Mängel der Websites blieben bestehen. Die Widgets halfen nicht.

Was mich an der Arbeit besonders beschäftigt, ist die Beobachtung zum Response Bias: Wenn Studienteilnehmende nach ihrer Wahrnehmung der Overlays gefragt wurden, fielen die Antworten zunächst positiver aus, als die objektiv gemessene Erfahrung vermuten ließ. Das Gefühl, endlich wahrgenommen zu werden – dass überhaupt etwas für die eigene Zugänglichkeit getan wird – scheint die Beurteilung zu verzerren. Kurz: Menschen sind dankbar für Aufmerksamkeit, auch wenn die konkrete Maßnahme nichts bringt.

Overlay-Anbieter stützen ihre Wirksamkeitsnachweise häufig auf genau solche subjektiven Bewertungen und auf White Papers, die sie selbst in Auftrag gegeben haben. Kubeschs Arbeit zeigt, warum das keine belastbare Grundlage ist.

Farbfehlsichtigkeit: Wenn „Hilfe” das Problem verkennt

Ich bin selbst farbfehlsichtig und engagiere mich in diesem Bereich auch vereinsgebunden. Das gibt mir eine andere Perspektive auf Overlays, als ich sie aus rein technischer Sicht hätte.

Viele Overlays bieten Modi für Farbfehlsichtigkeit an – Deuteranopia, Protanopia, Tritanopia. Klingt durchdacht. Ist es in der Theorie vielleicht. In der Praxis scheitert es oft schon daran, dass die Umfärbe-Algorithmen simpel bis grob sind und echte Inhalte verfälschen können. Problematischer ist aber das dahinterliegende Missverständnis: Farbfehlsichtigkeit ist kein Problem, das man durch eine CSS-Farbverschiebung löst. Es ist ein Problem, das durch schlechtes Informationsdesign entsteht – wenn Farbe die einzige Unterscheidungsmöglichkeit ist, wenn Diagramme nur farbkodiert sind, wenn Links sich nur durch Farbe vom Fließtext abheben.

Das lässt sich nicht durch ein Widget lösen. Das muss in der Gestaltung selbst gedacht werden. Ein Overlay, das einem Deuteranopen ein schlechtes Farbschema in ein anderes schlechtes Farbschema überführt, hat das eigentliche Problem nicht verstanden.

Falsches Sicherheitsgefühl auf beiden Seiten

Für viele Betroffene – und für die Betreiber ihrer Websites – erzeugen Overlays vor allem eines: die Illusion, das Problem sei gelöst. Das ist, offen gesagt, schlimmer als gar nichts zu tun.

Was die Überwachungsstellen sagen

Das ist keine Einzelmeinung aus der Community. Die BFIT-Bund – die Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik – hat im August 2022 eine Stellungnahme zu Overlay-Tools (öffnet in neuem Tab) veröffentlicht, die mit allen 16 Überwachungsstellen der Länder abgestimmt wurde. Das Ergebnis ist eindeutig: Overlay-Tools sind derzeit nicht in der Lage, einen Webauftritt, der Barrieren aufweist, vollständig barrierefrei darzustellen. Durch den Einsatz solcher Tools können sogar weitere Barrieren entstehen.

Amtliche Einschätzung der BFIT-Bund

„Eine nachträglich durch Software erzeugte, gegebenenfalls erst nach Einstellungen durch nutzende Personen temporär barrierefreie Darstellung eines Webauftrittes genügt den Anforderungen der vorgenannten gesetzlichen Vorschriften nicht.”

Das ist keine Grauzone. Das ist amtlich.

Auch das European Disability Forum (EDF) und der Deutsche Blinden- und Sehbehindertenverband (DBSV) warnen explizit vor der Annahme, Overlays könnten eine vollständige Lösung darstellen. Der DBSV empfiehlt stattdessen, vorhandene Kapazitäten in die barrierefreie Gestaltung der Online-Medien selbst zu investieren. Kurz gesagt: die Fachleute, die Betroffenenverbände und die zuständigen Behörden sagen alle dasselbe. Wer Overlays trotzdem mit Konformitätsversprechen verkauft, verkauft gegen den Konsens der gesamten Branche.

Kein Ersatz für echte Tests – und kein Freifahrtschein bei Audits

Ein weiterer Punkt, der in der Praxis häufig missverstanden wird: Das Vorhandensein eines Overlays zählt bei Accessibility-Prüfungen nichts. Weder bei BITV-Tests noch bei WCAG-Audits noch bei behördlichen Kontrollen durch die Überwachungsstellen.

Geprüft wird die Website selbst. Der zugrundeliegende Code. Die semantische Struktur. Die tatsächliche Bedienbarkeit mit Screenreader, Tastatur, vergrößertem Text. Und zwar unabhängig davon, ob ein Widget obendrauf liegt oder nicht. Was der Overlay versucht zu reparieren, muss im Original nicht kaputt sein – so lautet die eigentliche Anforderung.

Dazu kommt: Das Overlay darf nichts kaputtmachen, was ohne es funktioniert hätte. Und genau das passiert regelmäßig. Overlays greifen in den DOM ein, überschreiben ARIA-Attribute, manipulieren Fokus-Management. Eine Seite, die ohne Overlay halbwegs funktioniert, kann durch ein schlecht implementiertes Widget für Screenreader-Nutzerinnen und -Nutzer unbrauchbar werden. Das ist kein theoretisches Risiko – das ist dokumentierte Praxis.

Für öffentliche Stellen und BFSG-pflichtige Unternehmen

Ein Overlay kaufen und sich damit sicher fühlen ist nicht nur wirkungslos – es kann die Prüfsituation aktiv verschlechtern. Das Widget schützt weder vor Beanstandungen durch die Überwachungsstellen noch vor den Anforderungen des BFSG.

Der Vertrieb: Zwischen Halbwahrheiten und Druckaufbau

Ich habe in den vergangenen Jahren mehrfach direkte Kontakte zu Overlay-Anbietern gehabt – teils durch Kunden, die angefragt wurden, teils durch Konferenzen, teils durch direkte Akquise. Was ich dabei erlebt habe, macht mir ehrlich gesagt mehr Sorgen als die technischen Mängel.

Die Vertriebsargumentation ist oft erschreckend schwach – und gleichzeitig erschreckend effektiv. Aussagen wie „Mit unserem Widget sind Sie WCAG-konform” oder „Das schützt Sie vor Abmahnungen” werden gemacht, als wären sie rechtlich belastbare Fakten. Das sind sie nicht. WCAG-Konformität ist kein Zertifikat, das man kaufen kann. Und ein JavaScript-Widget, das rein clientseitig arbeitet, kann keine vollständige Konformität herstellen – das ist technisch schlicht unmöglich.

Besonders bemerkenswert: Einige Anbieter berufen sich auf gesetzliche Regelungen, die für den jeweiligen Kunden gar nicht zutreffen. Das BFSG etwa verpflichtet private Unternehmen im B2C-Bereich ab dem 28. Juni 2025 zu barrierefreien Produkten und Dienstleistungen – aber längst nicht jedes Unternehmen fällt darunter, und die Anforderungen betreffen weit mehr als eine Website. Wenn ein Vertriebsmitarbeiter einem kleinen Handwerksbetrieb suggeriert, er müsse sofort ein Overlay kaufen, weil sonst Abmahnungen drohen, dann ist das im günstigsten Fall schlecht recherchiert und im ungünstigsten Fall bewusste Desinformation.

Das schafft Druck, ohne Wissen zu schaffen. Genau das ist das Problem.

Wer braucht eigentlich wen?

Ein Argument, das Overlay-Anbieter gerne bringen: Menschen mit Behinderungen könnten die Einstellungen selbst wählen, die sie brauchen. Klingt nutzerfreundlich. Stimmt aber nicht mit der Realität überein.

Wer auf einen Screenreader angewiesen ist, hat diesen eingerichtet. Auf Betriebssystemebene. Mit den Einstellungen, die zu ihm passen – NVDA, JAWS, VoiceOver, TalkBack, je nach Gerät und Kontext. Ein Overlay-Widget, das versucht, den Screenreader zu unterstützen oder zu verbessern, kollidiert in der Praxis häufig mit genau diesem. Es gibt dokumentierte Fälle, in denen Overlays aktiv den Screenreader-Zugang verschlechtert haben – weil sie in den DOM eingreifen, ARIA-Attribute überschreiben oder das Fokus-Management manipulieren.

Wer auf Großdarstellung angewiesen ist, nutzt die OS-Einstellungen oder den Browserzoom. Wer hohen Kontrast braucht, stellt das systemweit ein. Browser und Betriebssysteme bieten heute umfangreiche Accessibility-Features – und die haben den entscheidenden Vorteil, dass sie konsistent sind, zuverlässig funktionieren und für den Nutzer da sind, wo und wann er sie braucht. Nicht nur auf Seiten mit einem installierten Widget.

Die Faustregel

Wer auf assistive Technologie angewiesen ist, richtet sie einmal systemweit ein – und erwartet dann, dass Websites damit funktionieren. Nicht andersherum.

Was wirklich hilft

Echte Barrierefreiheit entsteht im Entwicklungsprozess, nicht darüber. Sie beginnt mit sauberem, semantisch korrektem HTML. Mit Farbkontrasten, die von Anfang an stimmen. Mit Interaktionsmustern, die tastatur- und screenreader-zugänglich sind. Mit Tests durch echte Nutzerinnen und Nutzer mit Behinderungen.

Das ist mehr Arbeit. Das kostet mehr. Das ist nicht mit einem Script-Tag erledigt. Aber es ist das Einzige, was tatsächlich funktioniert.

Overlays sind kein Einstieg in Barrierefreiheit. Sie sind eine Ausrede dafür, keinen zu machen. Und wer sie kauft, weil der Vertrieb rechtliche Angst gemacht hat, hat am Ende weder echte Barrierefreiheit noch echte rechtliche Sicherheit – sondern nur ein Widget auf der Seite und ein schlechtes Gewissen weniger.

Das ist kein gutes Tauschgeschäft.