Macht ein Barrierefreiheits-Widget meine Website rechtlich barrierefrei?

Nein. Ein Overlay ist ein sichtbarer, sofort wirksamer Schritt und hilft vielen Besuchern, ersetzt aber keine barrierefreie Grundstruktur. Vollständige Konformität nach WCAG und dem Barrierefreiheitsgesetz braucht auch sauberes Markup, ausreichende Kontraste und Bedienbarkeit per Tastatur.

Warum blockiert eine strenge CSP viele Accessibility-Overlays?

Weil die meisten Overlays ein Remote-Skript von einem fremden Server laden und ihr CSS über einen injizierten style-Tag einfügen. Eine strenge Content-Security-Policy (script-src self, style-src self ohne unsafe-inline) verbietet genau das — das Widget lädt gar nicht erst oder erscheint ohne Styling.

Ist digitale Barrierefreiheit in Österreich und Deutschland Pflicht?

Ja. Seit 28. Juni 2025 gilt in Österreich das Barrierefreiheitsgesetz und in Deutschland das Barrierefreiheitsstärkungsgesetz. Verstöße können abgemahnt und mit Verwaltungsstrafen bis zu 80.000 € in Österreich und Bußgeldern bis zu 100.000 € in Deutschland geahndet werden.

Barrierefreiheits-Overlays und strenge CSP: warum die meisten Widgets scheitern

Die meisten Barrierefreiheits-Overlays scheitern auf genau den Seiten, die es am ernstesten meinen: solche mit einer strengen Content-Security-Policy (CSP). Entweder das Widget lädt nicht — oder man muss die Sicherheitsregeln aufweichen, damit es funktioniert. Beides ist vermeidbar. Dieser Beitrag zeigt, woran es liegt und wie ich das Problem beim Barrierefreiheits-Button auf dieser Seite gelöst habe.

Was eine Content-Security-Policy überhaupt tut

Eine CSP ist eine Browser-Regel, die festlegt, aus welchen Quellen eine Seite Skripte, Styles, Schriften und Bilder laden darf. Sie ist eine der wirksamsten Schutzmaßnahmen gegen Cross-Site-Scripting. Eine strenge Policy erlaubt typischerweise nur Ressourcen von der eigenen Domain (script-src 'self') und verbietet inline eingefügtes CSS und JavaScript ('unsafe-inline').

Genau diese vernünftige Härtung bringt handelsübliche Overlays zu Fall.

Warum die üblichen Overlays daran zerbrechen

Ein typisches Accessibility-Overlay tut zwei Dinge, die eine strenge CSP verbietet:

Es lädt ein Remote-Skript von einem fremden CDN. script-src 'self' blockiert das — das Widget startet nie.
Es fügt sein CSS über einen injizierten <style>-Block ein. style-src 'self' ohne 'unsafe-inline' blockiert das — der Button erscheint ohne Layout.

Der bequeme „Ausweg“ ist fatal: Man lockert die CSP ('unsafe-inline', fremde Hosts auf die Whitelist) — und schwächt damit den Schutz der ganzen Seite, nur um ein Zugänglichkeits-Widget zu betreiben. Das ist die falsche Richtung.

Ein Widget kann sich vollständig an eine strenge CSP halten, wenn es vier Prinzipien befolgt. So funktioniert der Button auf dieser Seite:

Selbst gehostet, kein CDN. Eine einzige JavaScript-Datei liegt auf deiner eigenen Domain. script-src 'self' ist damit erfüllt.
Styling über die CSSOM, nie über injiziertes <style>. Das Widget setzt sein Aussehen über constructable stylesheets (adoptedStyleSheets) und element.style — Wege, die eine CSP gar nicht kontrolliert. Kein 'unsafe-inline' nötig.
Eigene Oberfläche im Shadow DOM. Die UI des Widgets lebt in einem abgeschotteten Bereich. Das CSS der Seite kann das Widget nicht kaputt machen, und das Widget nicht die Seite.
Keine Netzwerkaufrufe zur Laufzeit. Der große Mauszeiger ist eine data:-URI, die Legasthenie-Schrift liegt auf derselben Domain, und das Vorlesen nutzt die eingebaute speechSynthesis des Browsers. Nichts verlässt das Haus.

Das Ergebnis: Auf einer Seite, die ihre eigenen Skripte, Schriften und data:-Bilder ohnehin erlaubt, sind keine CSP-Änderungen nötig. Sicherheit und Barrierefreiheit schließen sich nicht aus.

Datenschutz ist der zweite blinde Fleck

Viele Overlays sammeln im Hintergrund Nutzungsdaten oder laden Ressourcen von Drittservern — ein DSGVO-Problem, das man einer Zugänglichkeitshilfe nicht ansieht. Ein Widget, das ausschließlich auf deiner Domain läuft, kein Tracking betreibt und die Einstellungen der Besucher nur lokal im Browser (localStorage) speichert, hat dieses Problem nicht. Das ist kein Bonus, sondern die Grundvoraussetzung, damit eine Barrierefreiheitshilfe nicht selbst zum Rechtsrisiko wird.

Die ehrliche Einordnung: Overlay ≠ Konformität

Ein Overlay ist ein sinnvoller erster Schritt — und keine vollständige Lösung. Es hilft Besuchern mit Sehschwäche, Legasthenie oder motorischen Einschränkungen sofort, ihre Ansicht anzupassen: Kontrast, Textgröße, Zeilenabstand, Vorlesen. Was es nicht leistet: Es repariert keine fehlende Tastaturbedienbarkeit, keine unzureichenden Kontraste im Grunddesign und kein kaputtes HTML-Markup.

Vollständige Konformität nach den Web Content Accessibility Guidelines (WCAG) und dem seit 28. Juni 2025 geltenden Barrierefreiheitsgesetz (Österreich) bzw. Barrierefreiheitsstärkungsgesetz (Deutschland) verlangt sauberes Markup, semantische Struktur und Bedienbarkeit ohne Maus. Wer nur ein Overlay einbaut und den Rest ignoriert, hat ein gutes Gefühl, aber keine Konformität.

Der pragmatische Weg für kleine Betriebe: das Widget als sofort sichtbaren Schritt einbauen — und die Grundstruktur dort nachbessern, wo es wirklich zählt. Genau so gehe ich bei Barrierefreiheit vor: erst der schnelle, ehrliche erste Schritt, dann die saubere Basis. Übrigens läuft der Button live auf dieser Seite — unten rechts. Wenn du wissen willst, wo dein Auftritt steht: schreib mir.