Overlays: Warum sie scheitern – und warum das kein Zufall ist

Regelmäßig stoße ich in Audits auf das gleiche Muster: Eine Website hat ein Overlay-Skript eingebunden – UserWay, AccessiBe, EqualWeb oder eines von Dutzenden Konkurrenten. Die Person, die mich beauftragt, erklärt mir, dass Barrierefreiheit damit „abgedeckt” sei.

Dann gehen wir die Seite durch. Mit Screenreader. Mit Tastatur. Mit verschiedenen Geräten und Einstellungen.

Das Ergebnis ist immer dasselbe.

Was Overlays versprechen

Das Versprechen ist einfach formuliert: Skript einbinden, Widget auf der Website, automatisch zugänglich für alle. Manche Anbieter werben damit, dass ihre KI kontinuierlich die Seite analysiert und verbessert. Andere bieten rechtliche Absicherung an – eine Garantie gegen Klagen.

Der Preis liegt typischerweise zwischen 50 und 500 Euro im Monat. Verglichen mit einem professionellen Audit – der schnell mehrere Tausend Euro kosten kann – klingt das verlockend.

Das ist kein Zufall. Es spricht direkt die Entscheidungsebene an, die schnelle Compliance zu günstigem Preis sucht.

Warum das technisch nicht funktionieren kann

Barrierefreiheit ist kein Layer, den man über eine Website legen kann. Sie ist strukturell.

Das ARIA-Injektions-Problem

Overlays injizieren ARIA-Attribute und Rollen in den DOM, um Barrierefreiheitsprobleme zu „lösen”. Das klingt hilfreich. In der Praxis entsteht oft Folgendes:

<!-- Original: ein Div, das als Button dient -->
<div onclick="handleClick()">Absenden</div>

<!-- Nach Overlay-Injektion -->
<div onclick="handleClick()" role="button" aria-label="Absenden">Absenden</div>

Das role="button" teilt dem Screenreader mit, dass dies ein Button ist. Was es nicht löst: Die fehlende Tastaturinteraktion. Kein tabindex, kein keydown-Handler für Enter oder Leertaste. Für Tastaturnutzer ist das Element weiterhin nicht erreichbar – das Overlay hat das Problem sichtbarer gemacht, aber nicht gelöst.

WCAG 4.1.2 (Name, Role, Value) verlangt, dass der Name, die Rolle und der Wert eines Elements programmatisch bestimmbar sind. Aber WCAG 2.1.1 (Keyboard) verlangt darüber hinaus, dass alle Funktionen per Tastatur erreichbar sind. Rolle und Name allein reichen nicht.

Dynamischer Content

Moderne Webseiten laden Inhalte nach: Single-Page-Applications, dynamische Filter, AJAX-Anfragen. Overlays basieren häufig auf initialen DOM-Analysen. Was danach passiert – wenn Inhalte nachladen, wenn der Nutzer interagiert, wenn sich der Zustand ändert – liegt außerhalb des Bearbeitungsfensters des Overlays.

Das Ergebnis: Inkonsistentes Verhalten. Manchmal funktioniert etwas, manchmal nicht – abhängig von Ladezeitpunkt, Browser und Gerät.

Erraten statt Verstehen

Automatische Alt-Text-Generierung ist eines der meistbeworbenen Features von Overlays. Ein Bild wird gescannt, ein Alt-Text wird erraten – per Bilderkennung oder aus dem Dateinamen.

WCAG 1.1.1 fordert Textalternativen für alle nicht-textuellen Inhalte. Ein erraten Alt-Text kann formal vorhanden, aber inhaltlich falsch oder irreführend sein – was den Aufwand für Screenreader-Nutzer sogar erhöhen kann.

Warum Overlays aktiv schaden können

Es geht nicht nur darum, dass Overlays das Problem nicht lösen. In einigen Fällen verschlechtern sie die Erfahrung aktiv.

Einige Overlays injizieren JavaScript, das mit bestehenden Screenreadern interferiert. JAWS, NVDA und VoiceOver arbeiten auf Basis des DOM-Modells und der ARIA-Semantik. Wenn ein Overlay zusätzliche Attribute und Rollen hinzufügt, die nicht zum ursprünglichen Code passen, kann das zu widersprüchlichen Aussagen führen: Der Screenreader liest etwas anderes vor als der Nutzer erwartet.

Einige Nutzer haben sogar begonnen, Overlays mit Browser-Extensions zu blockieren – weil die Seite ohne Overlay besser nutzbar ist als mit.

Was die Rechtslage bedeutet

Der häufigste Einwand: „Aber wir haben damit unsere Haftung reduziert.” Das stimmt so nicht.

In Deutschland, der EU und den USA haben Gerichte in den vergangenen Jahren wiederholt entschieden, dass ein Widget nicht von der gesetzlichen Pflicht zur Barrierefreiheit entbindet. Der American with Disabilities Act (ADA), das BFSG und die EN 301 549 bewerten das Ergebnis – nicht das verwendete Tool.

Ein Overlay kann im besten Fall die Ausgangslage verbessern. Es kann im schlechtesten Fall als Versuch interpretiert werden, eine Pflicht mit unzureichenden Mitteln zu erfüllen – was die Rechtslage sogar verschlechtert.

Was stattdessen funktioniert

Es gibt keine kurze Antwort. Barrierefreiheit entsteht durch strukturelle Entscheidungen – nicht durch nachträgliche Eingriffe.

Konkret bedeutet das:

• Semantisches HTML als Grundlage: Das richtige Element für den richtigen Zweck. <button> für Buttons, <nav> für Navigation, <label> für Formularfelder. Nicht <div> für alles.
• Tastaturnavigation als Designprinzip: Jede Funktion, jede Interaktion muss ohne Maus erreichbar sein. Das beginnt im Konzept, nicht im QA-Prozess.
• Kontrast im Design-System verankern: Wenn Farbentscheidungen getroffen werden, müssen Kontrastverhältnisse mitgedacht werden – WCAG 1.4.3 (4.5:1 für Normtext), WCAG 1.4.11 (3:1 für grafische Objekte und Fokusindikatoren).
• Alt-Texte als redaktionellen Prozess: Wer Bilder einstellt, muss Alt-Texte schreiben – mit Kontext und Zweck, nicht mit Bildbeschreibung.
• Tests mit echten Assistenztechnologien: NVDA + Firefox, VoiceOver + Safari, Tastaturnavigation ohne Maus. Kein automatisiertes Tool ersetzt das.

Das ist mehr Aufwand als ein Skript einzubinden. Es ist der einzige Weg, der tatsächlich funktioniert – und der einzige, der langfristig vor rechtlichen Risiken schützt.