Barrierefreiheits-Overlays und der EAA: warum ein Widget Ihre Website nicht konform macht
Seit der European Accessibility Act am 28. Juni 2025 in Kraft getreten ist, landet in fast jedem europäischen Webteam dasselbe Verkaufsversprechen: Binden Sie diese eine Zeile JavaScript ein, und Ihre Website ist über Nacht konform. Das Produkt ist ein Barrierefreiheits-Overlay, ein Widget in einer Ecke der Seite, das größere Schrift, mehr Kontrast, einen „Screenreader-Modus“ und in den ehrgeizigeren Versionen maschinell erzeugte Alternativtexte anbietet.
Es lohnt sich, genau hinzusehen, was diese Werkzeuge tun, denn das Risiko liegt in der Lücke zwischen Versprechen und Rechtslage.
Was ein Overlay tatsächlich verändert
Ein Overlay läuft nachdem die Seite geladen ist, im Browser des Besuchers. Es kann umgestalten, was schon da ist: Schrift vergrößern, Farben invertieren, Animationen anhalten, Links umranden. Manche versuchen zusätzlich, den Code im Vorbeigehen zu flicken, indem sie einem Bild ohne Alternativtext einen raten oder einen unbeschrifteten Button mit einem aus dem Symbol abgeleiteten Label versehen.
Daraus folgen drei Dinge, die für den EAA zählen:
- Es ändert Ihren Code nicht. Das HTML, das Ihr Server ausliefert, ist genauso barrierefrei oder barrierebehaftet wie vorher. Jedes Audit, jeder Screenreader, der das Widget nicht lädt, jeder Crawler und jede Konformitätsbewertung sieht die ursprüngliche Seite.
- Es hilft nur denen, die das Widget finden und nutzen. Die meisten Besucher mit Behinderung kommen mit eigener, bereits eingerichteter Hilfstechnik: Screenreader, Braillezeile, Taster, Vergrößerung. Sie haben keine zweite, unbekannte Ebene darüber verlangt, und eine gut dokumentierte Beschwerde aus dieser Gruppe lautet, dass diese Ebene den Werkzeugen im Weg ist, auf die sie angewiesen sind.
- Geratenes bleibt geraten. Eine Maschine, die einen „Absenden“-Button als „Pfeilsymbol“ beschriftet, hat Ihren Bestellprozess nicht barrierefrei gemacht. Sie hat den Fehler in einem Testbericht nur schwerer sichtbar gemacht.
Was der EAA stattdessen verlangt
Die Richtlinie (EU) 2019/882 (in Deutschland umgesetzt durch das Barrierefreiheitsstärkungsgesetz, BFSG) erwähnt weder Widgets noch Siegel oder Anbieter. Sie legt funktionale Barrierefreiheitsanforderungen für die erfassten Produkte und Dienstleistungen fest (E-Commerce, Bankdienstleistungen, Verkehr, E-Books, Telekommunikation und weitere) und verweist auf die harmonisierte Norm EN 301 549, die für Webinhalte den Erfolgskriterien von WCAG 2.1 Stufe AA entspricht.
Diese Kriterien betreffen das, was Sie ausliefern: Hat jedes Bild eine Textalternative, jedes Formularfeld einen Namen, lässt sich der ganze Weg per Tastatur abschließen, ist die Fokusreihenfolge sinnvoll, ist der Kontrast von Haus aus ausreichend, werden Fehler in Textform beschrieben. Und sie betreffen die Organisation: Der Dienst muss eine Barrierefreiheitserklärung haben, erklären, wie er die Anforderungen erfüllt, auflisten, was noch nicht erfüllt ist, und den Menschen einen Weg geben, Probleme zu melden.
Die Marktüberwachungsbehörden jedes Mitgliedstaats können einen Wirtschaftsakteur auffordern, die Konformität nachzuweisen. Erwartet wird eine Bewertung gegen die Norm samt Dokumentation. „Wir haben ein Plugin installiert“ ist keine Bewertung, und kein Overlay-Anbieter unterschreibt Ihre Erklärung für Sie.
Der EAA legt die Pflicht dem Wirtschaftsakteur auf. Tests und Korrekturen können Sie auslagern. Die Verantwortung können Sie nicht an ein Script-Tag auslagern.
Die Vorgeschichte
Der Overlay-Markt ist in den USA unter dem ADA gewachsen, und dort gibt es die längste Erfahrung. Zwei Fakten genügen zur Einordnung:
- Mehrere Jahre in Folge richtete sich ein erheblicher Teil der in den USA eingereichten Klagen zur Web-Barrierefreiheit gegen Websites, auf denen bereits ein Overlay installiert war. Das Widget hat die Beschwerde nicht verhindert, denn sie betraf den Code darunter.
- Im Januar 2025 verpflichtete die US-Handelsbehörde FTC einen der größten Overlay-Anbieter zur Zahlung von einer Million Dollar wegen der Behauptung, sein Produkt könne jede Website konform mit Barrierefreiheitsrichtlinien machen. Die FTC befand, dass diese Behauptungen nicht belegt waren.
Mehr als achthundert Fachleute für Barrierefreiheit, viele davon selbst Nutzer mit Behinderung, haben eine öffentliche Erklärung unterzeichnet, die Website-Betreiber bittet, sich nicht auf Overlays zu verlassen. Das ist ein ungewöhnliches Maß an Einigkeit in einem Fachgebiet, das über fast alles streitet.
Wann ein Overlay nicht schadet
Das heißt nicht, dass die Widgets nutzlos sind. Ein Besucher ohne Hilfstechnik, der bei einem langen Artikel einfach größere Schrift möchte, hat etwas von einem Schriftgrößenregler. Wenn Sie bereits eine barrierefreie Website haben und ein Widget als Komfortfunktion ergänzen, ist das Widget nicht das Problem.
Das Problem ist die Reihenfolge. Das Widget kommt auf eine barrierefreie Website, es ersetzt sie nicht. Wenn Ihr Budget entweder das Overlay-Abo oder zwei Tage eines Entwicklers abdeckt, der Labels und Fokusreihenfolge in Ihren Vorlagen korrigiert, bringt Sie nur die zweite Option dem Gesetz näher.
Was stattdessen zu tun ist
Ein praktischer Weg, den wir bei kleinen und mittleren Anbietern funktionieren sehen:
- Die echten Nutzerwege prüfen, nicht die ganze Website. Registrierung, Suche, Warenkorb, Bezahlung, Kontakt. Jeden Weg nur mit Tastatur und mit einem Screenreader testen, dann für den Rest einen automatischen Scan laufen lassen. Automatische Werkzeuge erfassen etwa ein Drittel der Kriterien; der Rest braucht einen Menschen.
- In den Vorlagen beheben. Eine korrigierte Komponente repariert jede Seite, die sie nutzt, und bleibt auch nach dem nächsten Deployment repariert.
- Die Barrierefreiheitserklärung schreiben, solange das Audit frisch ist: was konform ist, was noch nicht, bis wann, und wie man ein Problem meldet. Veröffentlichen Sie sie dort, wo Besucher sie mit einem Klick finden.
- Barrierefreiheit in den Einkauf aufnehmen. Verlangen Sie von jedem Anbieter einer Komponente, eines Themes oder Plugins eigene Konformitätsnachweise. Von dort kommen die meisten Rückschritte.
- Bei jedem Release erneut testen. Eine kurze Checkliste in der Pull-Request-Vorlage bewirkt mehr als jedes jährliche Audit.
Wenn Sie einen ersten Eindruck vom Stand einer Website möchten, bevor Sie darüber entscheiden, ist ein automatischer Scan gegen EN 301 549 ein vernünftiger erster Schritt, solange allen klar ist, dass er der Anfang der Bewertung ist und nicht ihr Ende.