Accessibility-Overlays: kein Ersatz für BFSG-Konformität

Ein Accessibility-Overlay ist ein JavaScript-Widget, das über ein eingebettetes Skript geladen wird. Nachdem die Seite im Browser gerendert ist, greift das Skript in das Dokumentmodell (DOM) ein und blendet eine Bedienleiste ein, meist ein rundes Symbol am Bildschirmrand. Entscheidend ist der Zeitpunkt: Das Overlay arbeitet ausschließlich clientseitig, nach dem Laden, und verändert die zugrunde liegenden HTML-Vorlagen nicht. Der Quellcode, den Suchmaschinen, Hilfstechnologien und Prüfstellen sehen, bleibt unverändert.

Funktional lassen sich zwei Bausteine unterscheiden. Der erste ist eine Werkzeugleiste mit Darstellungsoptionen: Schrift vergrößern, Zeilenabstand erhöhen, Kontrast anpassen, einen Vorlesemodus starten. Das sind Voreinstellungen, die moderne Betriebssysteme und Browser vielen Nutzern ohnehin bereitstellen. Der zweite Baustein sind automatische Reparaturversuche: Das Skript versucht, fehlende Alt-Texte zu ergänzen oder ARIA-Attribute nachzurüsten. Genau dieser Teil weckt die Erwartung, das Widget könne strukturelle Mängel beheben, und genau hier liegt die größte Lücke zwischen Anspruch und Wirkung.

Die Vermarktung von Overlays folgt einem wiederkehrenden Muster: Barrierefreiheit sei eine Frage von Minuten, erledigt durch das Einbinden eines Skripts. Wer die Erfolgskriterien der WCAG 2.2 kennt, erkennt schnell, dass diese Zusagen die Komplexität der Anforderungen ausblenden. Die folgenden Behauptungen begegnen uns in Angeboten besonders oft.

Zwischen Marketing und Evidenz klafft eine Lücke. In der Befragung von Fachleuten für Barrierefreiheit durch WebAIM bewerteten 67 Prozent (WebAIM) der Teilnehmenden Overlay-Tools als wenig oder nicht wirksam. Unter den Befragten mit eigener Behinderung fiel das Urteil noch deutlicher aus: 72 Prozent (WebAIM) hielten die Tools für wenig oder nicht wirksam, und lediglich 2,4 Prozent (WebAIM) bewerteten sie als sehr wirksam. Gerade die Gruppe, deren Zugang Overlays verbessern sollen, äußert sich also besonders kritisch.

Der Grund liegt in der Technik der automatisierten Prüfung, auf der Overlays aufbauen. Nach Angaben des W3C und seiner Web Accessibility Initiative decken automatisierte Verfahren nur 30 bis 40 Prozent (W3C/WAI) der WCAG-Kriterien ab. Der WebAIM-Million-Report, der jährlich die Startseiten der eine Million meistbesuchten Websites analysiert, fand im Jahrgang 2024 durchschnittlich 56,8 (WebAIM Million, 2024) automatisch erkennbare Fehler pro Seite; zu geringer Textkontrast trat auf 81 Prozent (WebAIM Million, 2024) der Seiten auf. Diese Zahlen zeigen zweierlei: wie verbreitet Barrieren sind und wie begrenzt eine rein automatische Behandlung bleibt. Das Zusammenspiel automatisierter und manueller Tests ist deshalb durch kein Widget zu ersetzen.

Der Deutsche Blinden- und Sehbehindertenverband (DBSV) hat eine ausführliche Stellungnahme veröffentlicht. Kernaussage: Accessibility-Overlays sind nach dem heutigen Stand der Technik nicht in der Lage, eine Webseite von außen auf Knopfdruck barrierefrei zu gestalten (DBSV). Der Verband nennt konkrete Probleme im Alltag von Menschen, die auf Hilfstechnik angewiesen sind: Die Tastaturkommandos vieler Overlays sind nicht auf die Befehle gängiger Assistenztechnologien abgestimmt, sodass es zu Konflikten kommt. Bei modal eingeblendeten Overlay-Oberflächen vermischen sich Bedienelemente des Widgets und Elemente der Webseite, was die Screenreader-Nutzung erschwert. Manche Tools erlauben zudem Farbkombinationen, die den Tastatur- und Mausfokus unsichtbar machen (DBSV).

Auch die staatlichen Stellen positionieren sich klar. In einer gemeinsamen Einschätzung der Überwachungsstellen des Bundes und der Länder zum Einsatz von Overlay-Tools halten die Behörden fest, dass ein nicht barrierefreies Angebot durch ein Overlay nicht automatisch den rechtlichen Anforderungen genügt (Bundesfachstelle Barrierefreiheit). Beim gleichzeitigen Einsatz von Overlay und Hilfstechnik könne es sogar zu negativen Wechselwirkungen und einer Verschlechterung der Zugänglichkeit kommen. Die zentrale Aussage: Eine Website ist nur dann barrierefrei, wenn sie die Anforderungen auch ohne Overlay-Tool erfüllt (Bundesfachstelle Barrierefreiheit).

Das BFSG verlangt, dass die Dienstleistung selbst barrierefrei ist. Die technische Grundlage bildet die harmonisierte Norm EN 301 549, die für Web-Inhalte auf die WCAG verweist (EN 301 549). Ein Overlay ist nach dieser Logik kein Ersatz für Konformität, sondern eine zusätzliche Schicht über einer unveränderten Grundlage. Wer die Anforderungen des BFSG erfüllen will, kommt an einer Umsetzung im Quellcode nicht vorbei. Hinzu kommen weitere Pflichten wie eine Erklärung zur Barrierefreiheit und ein funktionierender Feedback-Mechanismus, die ein Widget nicht abbildet. Wie ein Verfahren im Ernstfall abläuft, beschreibt unser Beitrag dazu, wie das BFSG durchgesetzt wird.

Ein verbreiteter Irrtum ist die Vorstellung, ein Anbieter-Badge oder ein automatisch erzeugtes Konformitätszertifikat schütze vor Beschwerden. Im Prüffall verlangt die Marktüberwachung Nachweise, keine Werbeaussagen. Ein vom Overlay-Anbieter generiertes Siegel ist kein belastbarer Nachweis der Konformität. Auch dort, wo Erleichterungen greifen, etwa im Rahmen der Ausnahme für Kleinstunternehmen, ersetzt ein Overlay keine strukturelle Barrierefreiheit und keine Dokumentation.

Barrierefreiheit ist kein Effekt, der sich nachträglich über eine Seite legen lässt, sondern eine Eigenschaft, die in ihre Bausteine eingebaut wird. Sie entsteht an vier Orten: im Markup, im Design-System, in der Interaktionslogik und in der Redaktion. Ein Skript, das nach dem Laden eingreift, kann keinen dieser Orte dauerhaft ersetzen. Die barrierefreie Umsetzung setzt genau hier an.

Besonders die redaktionelle Dimension wird unterschätzt. Ob ein Alt-Text den Zweck eines Bildes im jeweiligen Kontext trifft, ob ein Linktext auch außerhalb des Satzes verständlich ist, ob ein Farbkontrast im Layout wirklich ausreicht: Das sind Bewertungen, die inhaltliches Verständnis erfordern. Wie stark schon Farbkontraste über die Lesbarkeit entscheiden, zeigt die Praxis täglich. Wer Teams gezielt schult, verankert Barrierefreiheit dauerhaft im Arbeitsablauf; unsere Redaktions- und Entwicklungsschulungen vermitteln die nötigen Routinen. Dieselbe Logik gilt über die Website hinaus, etwa für barrierefreie Apps, deren Zugänglichkeit ebenfalls im nativen Code entsteht.

Die folgende Gegenüberstellung fasst die wesentlichen Unterschiede zusammen. Sie ordnet Overlay-Widget und strukturelle Umsetzung entlang der Kriterien ein, die für BFSG-Konformität und für die reale Nutzererfahrung zählen.

Hat ein Overlay damit gar keinen Platz? Der DBSV sieht einen möglichen Zusatznutzen: als Ergänzung auf einer bereits eigenständig barrierefrei gestalteten Seite, etwa für individuelle Personalisierung. Als Ersatz für die Grundlage taugt es nicht. Wer den erreichten Stand halten will, kombiniert die strukturelle Umsetzung sinnvoll mit einem laufenden BFSG-Monitoring, das neue Barrieren frühzeitig erkennt.

Statt ein Widget einzubinden, das die Symptome verdeckt, lohnt der Blick auf die Ursachen. Ein WCAG-2.2-Audit verbindet automatisierte Scans mit manuellen Experten- und Screenreader-Tests und liefert als Ergebnis eine priorisierte Maßnahmenliste. Jeder Befund ist einem Erfolgskriterium zugeordnet und mit einem konkreten Lösungsvorschlag versehen. So wird Barrierefreiheit planbar und nachweisbar, statt sie an eine externe Blackbox auszulagern.

Aus dem Audit ergibt sich zugleich die Grundlage für die Erklärung zur Barrierefreiheit, die das BFSG verlangt. Ist der Umfang unklar, hilft ein kurzes Gespräch, den passenden Zuschnitt zu finden; unser Team ist über die Kontaktseite erreichbar. Der Aufwand zahlt sich aus: Eine strukturell barrierefreie Seite verbessert die Nutzererfahrung für alle, ist rechtlich nachweisbar und bleibt unabhängig von einem externen Skript.