Was ist ein Barrierefreiheits-Overlay?

Ein Overlay für Barrierefreiheit ist eine Softwareschicht, die auf eine bereits fertige Website aufgesetzt wird. In der Regel kommt es als JavaScript-Zeile, die in den Code der Seite eingefügt wird, oder als Plugin, das sich über das CMS aktivieren lässt. Beim Laden der Seite fügt das Skript einen schwebenden Button ein, fast immer in einer Ecke, der ein Menü mit visuellen Einstellungen öffnet: Schriftgröße, Kontrast, Cursor-Art, Pause für Animationen, teilweise Sprachausgabe.

Der Unterschied zur echten Barrierefreiheit liegt darin, wo die Änderung ansetzt. Eine echte Umsetzung arbeitet im Quellcode: korrekte HTML-Auszeichnung, ARIA-Attribute an interaktiven Bausteinen, Tastaturnavigation, die mit echten Nutzern getestet wurde, im Design berechneter Kontrast. Das Overlay dagegen greift von außen ein, nachträglich, auf eine Seite, die unter dem Einstellungsmenü dieselben strukturellen Probleme behalten kann.

Dieser Artikel bewertet nicht, ob Overlays legal oder illegal sind, denn keine Norm nennt sie ausdrücklich. Es gibt aber eine technische Grundlage und eine dokumentierte Haltung von Behindertenverbänden und Aufsichtsstellen gegen ihren Einsatz als vollständige Lösung. Diese Grundlage folgt im nächsten Abschnitt.

Der Mechanismus ist fast immer derselbe. Ein JavaScript-Ausschnitt läuft im Browser des Besuchers, durchsucht das DOM der Seite und wendet Änderungen live an: vergrößert Text, erhöht Kontrast, fügt fehlende ARIA-Attribute hinzu oder ändert sie, versucht Bilder ohne Alternativtext per automatischer Erkennung zu beschreiben.

Das Problem zeigt sich bei dem, was das Skript nicht leisten kann. Die WCAG 2.2, der technische Referenzstandard des W3C für barrierefreie Webinhalte, verlangen zum Beispiel, dass sich die gesamte Funktionalität per Tastatur bedienen lässt (Kriterium 2.1.1) und dass jede Bedienkomponente Name, Rolle und Zustand an Hilfstechnologien meldet (Kriterium 4.1.2). Ein Dropdown-Menü, das ohne Tastatur-Event-Handling programmiert wurde, bekommt dieses Handling nicht dadurch, dass ein Overlay einen sichtbaren Fokusrahmen ergänzt: Das fehlende Ereignis fehlt weiterhin. Und eine eigens gebaute Komponente, die nie eine Rolle definiert hat, bekommt diese nicht zuverlässig, weil ein externes Skript sie per Muster zu erraten versucht. Bei einfachen Buttons kann das gelingen, bei einem Karussell oder einem Formular mit eigener Validierung meist nicht.

Die automatische Bilderkennung hat dieselbe Grenze. Sie kann ein generisches Foto mit einem plausiblen Wort beschriften, weiß aber nicht, welche konkrete Information dieses Bild im jeweiligen Inhalt tragen sollte: eine Grafik mit Daten, ein als Icon getarnter Button, ein Screenshot mit eingebettetem Text. Die WCAG 2.2 verlangen einen Alternativtext, der die Funktion des Bildes erfüllt (Kriterium 1.1.1), keine ungefähre, kontextlose Beschreibung.

Deshalb sagt die technische Kritik nicht, Overlays würden gar nichts leisten. Sie sagt, sie wirken auf der sichtbaren Ebene und lassen die Verhaltensebene unangetastet, die ein Screenreader oder ein Tastaturnutzer braucht. In manchen Fällen entsteht sogar ein neues Problem: Wenn das Overlay Attribute überschreibt, die der Nutzer bereits in seinem eigenen Screenreader oder Browser eingestellt hatte, können beide Ebenen kollidieren, mit dem Ergebnis, dass die Seite hinterher weniger zugänglich ist als vorher.

Das Overlay wird oft als Ein-Zeilen-Lösung verkauft, um das Barrierefreiheitsstärkungsgesetz (BFSG) oder den European Accessibility Act zu erfüllen. Genau dieses Versprechen ist das Problem: Es macht aus einer technischen Entscheidung einen schnellen Kauf und lenkt das Budget, das eigentlich in die Korrektur des Quellcodes gehören würde, in ein monatliches Abonnement, das nicht an die Ursache herankommt.

Die Bfit-Bund und die 16 Überwachungsstellen der Bundesländer, also die staatlichen Marktaufsichtsbehörden für das BFSG, haben dazu am 20.08.2022 gemeinsam Stellung genommen: „Aktuell sind Overlay-Tools nicht in der Lage, einen Webauftritt, der Barrieren aufweist, komplett barrierefrei darzustellen.“ Und weiter: „Overlay-Tools und Hilfstechnologien [können] bei gleichzeitiger Nutzung zu negativen Wechselwirkungen führen…, wodurch die Zugänglichkeit des Webauftrittes verschlechtert werden kann.“ Das ist eine amtliche Einschätzung staatlicher Aufsichtsstellen, keine Einzelmeinung.

Der teure Teil des Fehlers kommt später. Wenn ein Unternehmen sich auf das Overlay verlässt und danach eine Beschwerde oder eine Prüfung durch die Marktaufsicht erhält, kann es nicht anführen, das Problem sei bereits gelöst. Die technische Grundlage erfüllt die Anforderungen weiterhin nicht, und die Ausgabe für das Overlay kommt zu den Kosten der eigentlichen Korrektur hinzu, die früher oder später ansteht.

Es gibt zudem einen grundlegenden Unterschied zwischen beiden Ausgabearten. Das Overlay-Abonnement wird Monat für Monat bezahlt, solange die Website existiert, ohne dass sich der Code dadurch verbessert. Die Korrektur im Quellcode ist eine einmalige Ausgabe, die dauerhaft in der Website steckt und nicht von einer laufenden Zahlung abhängt, um nicht wieder verloren zu gehen.

• Vor jeder Installation eine echte Prüfung nach WCAG 2.2 beauftragen, durchgeführt von einer Person; ein automatischer Scanner allein reicht nicht.
• Die Seite ohne Maus testen, nur mit Tastatur: durch alle Links, Buttons und Formulare tabben und prüfen, ob der Fokus sichtbar ist und nichts hängen bleibt.
• Mit einem echten Screenreader testen (NVDA, VoiceOver): Die Startseite allein reicht nicht, dazu gehören auch die meistbesuchten Seiten.
• Im Quellcode korrigieren, was fehlt: Alt-Texte, ARIA-Rollen, Farbkontrast, Überschriftenreihenfolge, Formulare mit verknüpften Labels.
• Jede Korrektur mit Datum dokumentieren, um die geleistete Arbeit bei einer Beschwerde belegen zu können.
• Wird ein Overlay eingesetzt, es als zusätzliche visuelle Hilfe für die Endnutzer behandeln, nie als Ersatz für die vorherige Arbeit.

• Das Overlay installieren und das Barrierefreiheitsprojekt als erledigt betrachten, ohne den Code anzufassen.
• Das Fehlen einer Norm, die Overlays verbietet, mit der Garantie verwechseln, dass sie die Anforderungen erfüllen.
• Die Seite nach der Installation nicht mit Tastatur oder Screenreader testen und annehmen, sie funktioniere, weil das visuelle Menü erscheint.
• Das Overlay zur einzigen Maßnahme gegen ein Barrierefreiheitsstärkungsgesetz mit echten Fristen und Sanktionen machen.
• Nicht prüfen, ob das Overlay mit den Hilfstechnologien kollidiert, die der Nutzer bereits auf seinem eigenen Gerät eingerichtet hat, und das erst nach einer Beschwerde bemerken.