Seit dem 28. Juni 2025 verpflichtet das Barrierefreiheitsstärkungsgesetz (BFSG) viele Online-Shops und Dienstleister, ihre digitalen Angebote barrierefrei zu gestalten. Im selben Atemzug versprechen Overlay-Widgets eine schnelle Lösung per Code-Schnipsel: ein kleines Skript einbinden, fertig. Doch genau hier liegt das Risiko. Overlays lösen die zugrundeliegenden Barrieren in der Regel nicht und können das BFSG-Risiko sogar erhöhen. Dieser Beitrag zeigt, warum echte [Barrierefreiheit1 im Code entstehen muss und wann ein Widget zur Falle wird.

Das Versprechen klingt verführerisch: eine Zeile JavaScript, und das Compliance-Thema sei abgehakt. Für viele Verantwortliche, die kurz vor oder nach dem Stichtag unter Druck geraten sind, wirkt das wie der rettende Ausweg. Tatsächlich verschiebt ein Overlay das Problem jedoch nur und kann es im ungünstigsten Fall vergrößern. Wer die Anforderungen des BFSG dauerhaft erfüllen will, kommt an einer Betrachtung des eigentlichen Quellcodes nicht vorbei. Genau dort, im strukturellen Aufbau der Seite, entscheidet sich, ob ein Angebot für alle nutzbar ist.

Was Overlay-Widgets versprechen und was sie tatsächlich tun

Ein Barrierefreiheits-Overlay ist ein JavaScript-Skript, das als zusätzliche Schicht über Ihre bestehende Website gelegt wird. Per Klick auf ein schwebendes Symbol öffnet sich ein Menü mit Optionen wie Schriftvergrößerung, Kontrastumschaltung oder einer Vorlesefunktion. Die Marketing-Botschaft lautet meist: eine Zeile Code, und Ihre Seite sei konform.

Der entscheidende Punkt ist jedoch: Ein Overlay verändert den Quellcode Ihrer Seite nicht. Fehlende Alternativtexte, eine unzureichende Überschriftenstruktur, nicht beschriftete Formularfelder oder mangelhafte Tastaturbedienung bleiben im HTML bestehen. Das Widget legt lediglich eine kosmetische Ebene darüber. Barrierefreiheits-Widgets gelten daher in der Fachwelt als ergänzende Werkzeuge, nicht als Ersatz für eine Behebung auf Code-Ebene (Wikipedia/Web accessibility).

Hinzu kommt eine technische Hürde, die oft übersehen wird: Ein Overlay greift erst, nachdem die Seite geladen ist und das Skript ausgeführt wurde. Assistive Technologien beginnen jedoch häufig schon vorher, das Dokument zu interpretieren. Was der Screenreader in diesem Moment vorfindet, ist das unveränderte, nicht barrierefreie HTML. Versucht das Overlay anschließend, Inhalte nachträglich umzuschreiben, entsteht im schlechtesten Fall ein bewegliches Ziel, das die assistive Technologie nicht zuverlässig nachvollziehen kann.

Auch der wirtschaftliche Anreiz hinter vielen Overlay-Angeboten verdient einen Blick. Sie werden oft im Abo-Modell verkauft, mit der Aussicht auf sofortige Konformität ohne Eingriff in die bestehende Seite. Dieses Versprechen ist verlockend, gerade unter Zeitdruck. Doch laufende Gebühren für ein Werkzeug, das die eigentlichen Barrieren nicht beseitigt, sind in der Regel weniger nachhaltig als eine einmalige, saubere Umsetzung im Code, die dauerhaft Bestand hat.

Der Kern des Problems

Die meisten Barrieren liegen in der Struktur und Semantik des HTML. Eine zusätzliche Skript-Schicht kann diese nicht zuverlässig reparieren, weil sie den darunterliegenden Code nicht ersetzt, sondern nur ergänzt.

Warum Overlays neue Barrieren schaffen können

Besonders kritisch ist die Wechselwirkung mit assistiven Technologien. Viele blinde und sehbehinderte Menschen nutzen einen Screenreader, der bereits tief in Betriebssystem und Browser integriert ist. Ein Overlay, das parallel eigene Vorlese- oder Navigationsfunktionen einblendet, kann mit dem Screenreader kollidieren und so neue Stolpersteine erzeugen, statt vorhandene abzubauen (audatis). Die Folge ist paradox: Ein Werkzeug, das Barrieren abbaün soll, errichtet im Einzelfall neü. Gerade für erfahrene Nutzerinnen und Nutzer, die ihre Hilfsmittel über Jahre eingerichtet haben, kann das frustrierend sein.

Die Skepsis ist breit dokumentiert. Der Overlay Fact Sheet ist eine Stellungnahme, die von rund 800 Fachleuten für Barrierefreiheit unterzeichnet wurde, darunter Mitwirkende an den WCAG-, ARIA- und HTML-Spezifikationen (Overlay Fact Sheet). Die Unterzeichnenden verpflichten sich, kein Overlay zu empfehlen, das sich fälschlich als automatische Erfüllung gesetzlicher Vorgaben darstellt. Auch die National Federation of the Blind hat Overlays als unzureichende Lösung verurteilt (Wikipedia/AccessiBe).

Wie ernst die Lage gesehen wird, zeigt ein juristischer Vorgang: 2024 wurde gegen einen bekannten Overlay-Anbieter eine Sammelklage eingereicht, mit dem Vorwurf, mehrere Werbeaussagen seien übertrieben und die Widgets stellten keine Konformität sicher, in einzelnen Fällen erschwerten sie die Nutzung sogar (Wikipedia/UserWay). Für Betreiber ist das ein Warnsignal: Wer sich auf das Konformitätsversprechen eines Werkzeugs verlässt, trägt am Ende selbst die Verantwortung für die tatsächliche Zugänglichkeit.

Ein Overlay kann eine Website nicht in einen Zustand versetzen, den der zugrundeliegende Code nicht hergibt. Es kaschiert Symptome, behebt aber nicht die Ursache.

Konsens der Barrierefreiheits-Fachwelt (Overlay Fact Sheet)
  • Doppelte Bedienelemente: Widget-Funktionen überlagern native Screenreader-Befehle und stiften Verwirrung.
  • Falsche oder automatische Beschriftungen: Maschinell generierte Alt-Texte sind oft ungenau und können Inhalte falsch wiedergeben.
  • Fokus-Fallen: Das schwebende Menü kann die Tastaturnavigation unterbrechen.
  • Performance-Ballast: Ein zusätzliches Skript verlangsamt den Seitenaufbau und beeinflusst die [Ladezeiten1.

Die Datenlage: Barrierefreiheit ist weiterhin die Ausnahme

Der WebAIM-Million-Report 2025 untersucht jährlich die Startseiten der eine Million meistbesuchten Websites. Das Ergebnis ist ernüchternd: 94,8% (WebAIM Million 2025) dieser Startseiten weisen erkennbare WCAG-2-A/AA-Fehler auf, ein nur marginaler Rückgang gegenüber 95,9% im Jahr 2024 (WebAIM Million 2025).

Im Schnitt fanden die Prüfer 51 Fehler pro Seite (WebAIM Million 2025). Bemerkenswert: Nur sechs wiederkehrende Fehlertypen sind für rund 96% (WebAIM Million 2025) aller Probleme verantwortlich. Mit Abstand am häufigsten ist zu geringer Textkontrast, der auf 79,1% (WebAIM Million 2025) der untersuchten Startseiten auftrat. Genau solche Fehler liegen in CSS und HTML und lassen sich von einem Overlay nicht zuverlässig beheben, wohl aber durch eine saubere Umsetzung im Code.

Steigende Komplexität

Die durchschnittliche Startseite wuchs von 1.173 Elementen im Februar 2024 auf 1.257 Elemente im Februar 2025, ein Plus von 7,1% (WebAIM Million 2025). Mehr Komplexität bedeutet mehr potenzielle Barrieren, die ein generisches Skript kaum erfassen kann.

Diese Zahlen sind kein Argument gegen technische Hilfen an sich, wohl aber gegen die Vorstellung, ein generisches Skript könne die Vielfalt realer Barrieren automatisch auflösen. Die häufigsten Fehlerarten, etwa zu geringe Kontraste oder fehlende Bildbeschreibungen, entstehen in der Gestaltung und im Markup. Sie lassen sich dort gezielt beheben, wo sie verursacht werden, und nicht über eine nachgelagerte Schicht, die das Original unangetastet lässt.

Wer vom BFSG betroffen ist

Das BFSG setzt die europäische Richtlinie über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen in deutsches Recht um. Betroffen sind seit dem 28. Juni 2025 unter anderem Anbieter im elektronischen Geschäftsverkehr, also typische Online-Shops, sowie weitere Dienstleistungen mit Endkundenbezug. Für viele Betreiber bedeutet das: Der gesamte Kaufprozess vom Produktlisting über die Detailseite bis zum Abschluss muss zugänglich sein.

Es gibt Ausnahmen, etwa für Kleinstunternehmen, die Dienstleistungen anbieten und bestimmte Schwellenwerte bei Beschäftigten und Umsatz unterschreiten. Diese Einordnung ist jedoch im Einzelfall zu prüfen und entbindet nicht automatisch von jeder Anforderung. Wer unsicher ist, ob das eigene Angebot in den Anwendungsbereich fällt, sollte das frühzeitig klären, statt auf ein Overlay als vermeintliche Absicherung zu setzen.

  • Online-Shops mit Verkauf an Verbraucherinnen und Verbraucher
  • Dienstleistungen im elektronischen Geschäftsverkehr mit Endkundenbezug
  • Buchungs- und Terminsysteme sowie Self-Service-Portale
  • Bestimmte Produkte mit digitaler Komponente, etwa Benutzeroberflächen

Das rechtliche Risiko unter dem BFSG

Das BFSG orientiert sich an den Anforderungen der harmonisierten europäischen Norm und damit an den WCAG. Maßgeblich ist die tatsächliche Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit Ihres Angebots, nicht die Anwesenheit eines Widgets. Wer sich allein auf ein Overlay verlässt, erfüllt die strukturellen Anforderungen in der Regel nicht (germanupa).

Bei Verstößen drohen spürbare Konsequenzen. Die Marktüberwachungsbehörde kann Auskunft verlangen und die Umsetzung der Anforderungen innerhalb einer Frist anordnen. Nach den Bußgeldvorschriften des Gesetzes können Bußgelder von bis zu 10.000 Euro und in bestimmten Fällen bis zu 100.000 Euro verhängt werden (§ 37 BFSG). Im äußersten Fall ist die Untersagung des Angebots möglich. Hinzu kommt das Abmahnrisiko über das Wettbewerbsrecht.

Wichtig ist die Beweislage. Ein Overlay liefert in der Regel keinen belastbaren Nachweis darüber, dass die einzelnen WCAG-Erfolgskriterien tatsächlich erfüllt sind. Eine strukturierte Umsetzung im Code dagegen lässt sich dokumentieren, etwa über Prüfberichte, eine nachvollziehbare Komponentenstruktur und reproduzierbare Tests. Diese Dokumentation ist nicht nur für eine mögliche Prüfung durch die Behörde hilfreich, sondern auch für die kontinuierliche Weiterentwicklung der Seite.

Verantwortung bleibt beim Betreiber

Auch wenn ein Anbieter mit automatischer Konformität wirbt: Die rechtliche Verantwortung für die Barrierefreiheit Ihres Angebots trägt in der Regel der Betreiber. Ein Werkzeug-Versprechen ersetzt diese Verantwortung nicht.

KriteriumOverlay-WidgetUmsetzung im Code
Quellcode wird korrigiertNeinJa
Kompatibel mit ScreenreadernEingeschränktJa
Deckt WCAG-Erfolgskriterien strukturell abTeilweiseUmfassend
BFSG-Nachweis möglichSchwierigJa, dokumentierbar
Beeinflusst Ladezeit negativHäufigNein
Nachhaltige LösungNeinJa

Häufige Mythen rund um Overlays

Rund um Overlay-Widgets halten sich einige Annahmen, die einer näheren Betrachtung selten standhalten. Es lohnt sich, sie offen anzusprechen, denn sie beeinflussen die Entscheidung vieler Betreiber unter Zeitdruck.

Mythos 1: Ein Overlay macht die Seite über Nacht konform. Tatsächlich bleibt der zugrundeliegende Code unverändert. Die strukturellen Anforderungen der WCAG werden dadurch in der Regel nicht erfüllt, und ein belastbarer Nachweis entsteht nicht.

Mythos 2: Nutzer mit Behinderung bevorzugen Overlay-Funktionen. Viele Betroffene nutzen ihre eigenen, fein konfigurierten Hilfsmittel. Eine zusätzliche, parallele Bedienebene kann diese stören statt unterstützen. Fachverbände haben Overlays als unzureichend bezeichnet (Wikipedia/AccessiBe).

Mythos 3: Ein Overlay ist günstiger als eine Umsetzung im Code. Auf den ersten Blick ja, durch die laufenden Abo-Gebühren und das fortbestehende rechtliche Risiko relativiert sich dieser Vorteil jedoch. Eine einmalige, saubere Umsetzung wirkt langfristig und muss nicht monatlich neu bezahlt werden.

Vorsicht bei Konformitäts-Versprechen

Aussagen wie automatische oder sofortige Konformität sollten kritisch hinterfragt werden. Barrierefreiheit ergibt sich aus der tatsächlichen Zugänglichkeit, nicht aus einer Werbeaussage.

Vom Overlay zur soliden Lösung

Wer bereits ein Overlay einsetzt, steht nicht vor einem Scherbenhaufen, sondern vor einem klaren nächsten Schritt. Der Weg führt von der aufgesetzten Schicht zu einer im Code verankerten Lösung, idealerweise in mehreren überschaubaren Etappen. Wichtig ist dabei, die bestehenden Inhalte nicht zu verlieren: Texte, Bilder und Funktionen bleiben erhalten, sie werden lediglich so aufbereitet, dass assistive Technologien sie korrekt verarbeiten können. So entsteht kein Bruch im Auftritt, sondern eine schrittweise Verbesserung der Substanz.

  1. Ist-Analyse: Eine kombinierte Prüfung aus automatischen Tools und manuellen Tests deckt auf, welche Barrieren tatsächlich bestehen.
  2. Priorisierung: Die häufigsten und gravierendsten Probleme, etwa Kontraste, fehlende Beschriftungen und Tastaturfallen, werden zuerst behoben.
  3. Umsetzung im Code: Die Korrekturen erfolgen direkt in Vorlagen und Komponenten, sodass sie auf allen betroffenen Seiten wirken.
  4. Test und Dokumentation: Die erreichte Zugänglichkeit wird nachvollziehbar belegt und mit Hilfsmitteln gegengeprüft.
  5. Overlay ablegen: Ist die Substanz tragfähig, kann die zusätzliche Skript-Schicht entfallen, inklusive ihrer laufenden Kosten.

Dieser Ablauf lässt sich gut mit ohnehin geplanten Vorhaben verbinden. Ein [Website- oder Shop-Relaunch1 ist ein natürlicher Zeitpunkt, Barrierefreiheit von Beginn an mitzudenken, statt sie später aufzusetzen.

Wie echte Barrierefreiheit im Code entsteht

Nachhaltige Barrierefreiheit beginnt im Markup und in der Gestaltung. Statt einer aufgesetzten Schicht werden die Inhalte selbst so strukturiert, dass sie für alle Nutzergruppen und assistiven Technologien zugänglich sind. Das ist die Grundlage unserer [BFSG-Optimierung1 und fließt in jedes [Programmier-Projekt2 ein.

Semantisches HTML

Korrekte Überschriftenhierarchie, Landmarks und native Elemente, damit Screenreader die Struktur verstehen.

ARIA mit Augenmaß

ARIA-Attribute nur dort, wo native Semantik nicht ausreicht, damit keine widersprüchlichen Informationen entstehen.

Tastatur-Bedienbarkeit

Alle Funktionen ohne Maus erreichbar, mit sichtbarem Fokus und logischer Reihenfolge.

Kontrast und Lesbarkeit

Ausreichende Farbkontraste und skalierbare Schrift, geprüft gegen die WCAG-2.1-AA-Kriterien.

Diese Prinzipien gelten unabhängig vom System. Ob ein individueller [Shopware-Shop1, eine [WordPress-Website2 oder eine maßgeschneiderte Anwendung: Barrierefreiheit wird in die Komponenten eingebaut, getestet und dokumentiert. Ein durchdachter [fairer Checkout-Prozess3 profitiert davon ebenso wie barrierearme Funktionen, etwa ein gut bedienbarer [Wunschzettel im Shop4.

In der Praxis beginnt eine saubere Umsetzung mit einer Bestandsaufnahme. Wo liegen die Barrieren, welche Vorlagen und Komponenten sind betroffen, und welche Erfolgskriterien sind besonders kritisch? Aus dieser Analyse entsteht ein priorisierter Plan, der zuerst die häufigsten und folgenreichsten Probleme adressiert, etwa Kontraste und Alternativtexte, und sich dann den komplexeren interaktiven Elementen widmet.

  • Überschriftenhierarchie und Landmarks prüfen und korrigieren
  • Alle Bedienelemente per Tastatur erreichbar machen, mit sichtbarem Fokus
  • Formularfelder eindeutig beschriften und Fehlermeldungen zugänglich gestalten
  • Farbkontraste gegen die WCAG-2.1-AA-Schwellen testen
  • Aussagekräftige Alternativtexte für Bilder und Grafiken ergänzen
  • Manuelle Tests mit Tastatur und Screenreader durchführen
Prüfung mit echten Hilfsmitteln

Automatische Tests erkennen nur einen Teil der Probleme. Eine belastbare Bewertung kombiniert Tools mit manuellen Tests, etwa per Tastaturnavigation und Screenreader, sowie idealerweise mit Nutzenden, die auf assistive Technologien angewiesen sind.

Ein wiederkehrender Vorteil dieser Vorgehensweise ist die Wartbarkeit. Weil die Barrierefreiheit in den Komponenten selbst lebt, profitieren auch neue Seiten und künftige Funktionen automatisch davon. Es entsteht kein paralleles System, das gepflegt und bezahlt werden muss, sondern ein Standard, der Teil der normalen Entwicklung ist.

Barrierefreiheit zahlt auf den Geschäftserfolg ein

Barrierefreiheit ausschließlich als Pflicht zu begreifen, greift zu kurz. Ein erheblicher Teil der Bevölkerung lebt mit dauerhaften oder vorübergehenden Einschränkungen, etwa des Sehens, Hörens oder der Motorik. Hinzu kommen situative Einschränkungen: grelles Sonnenlicht auf dem Smartphone-Display, eine laute Umgebung ohne Kopfhörer oder eine Hand, die gerade etwas anderes hält. Eine zugängliche Seite kommt all diesen Menschen zugute, nicht nur einer kleinen Gruppe.

Wer diese Nutzergruppen ausschließt, verschenkt Reichweite und Umsatz. Eine klare Struktur, gute Kontraste und eine durchdachte Bedienbarkeit verbessern die Nutzererfahrung für alle Besucher und können sich positiv auf Verweildauer, Abschlussraten und Wiederkehr auswirken. Genau die Eigenschaften, die eine Seite barrierefrei machen, sind häufig dieselben, die auch die [Conversion-Optimierung1 und die technische Qualität stützen.

Größere Reichweite

Inhalte werden für mehr Menschen und mehr Nutzungssituationen erreichbar.

Bessere SEO-Basis

Saubere Semantik und Struktur helfen auch Suchmaschinen beim Verstehen der Seite.

Weniger Rechtsrisiko

Eine dokumentierte Umsetzung verringert das Risiko von Abmahnungen und Bußgeldern.

Barrierefreiheit als nachhaltige Investition

Barrierefreiheit ist mehr als Pflichterfüllung. Eine zugängliche Seite erreicht mehr Menschen, verbessert die Nutzerfreundlichkeit für alle und wirkt sich oft positiv auf [Suchmaschinenoptimierung1 und Conversion aus, weil klare Struktur und gute Bedienbarkeit allen Besuchern helfen. Ein Overlay erkauft kurzfristige Beruhigung, schafft aber weder den rechtlichen Nachweis noch die tatsächliche Zugänglichkeit.

Wer das BFSG ernst nimmt, investiert daher in die Substanz statt in die Fassade. Eine strukturierte Umsetzung im Code schafft eine belastbare Grundlage, die sich auch bei steigender Komplexität und künftigen Erweiterungen trägt. Entscheidend ist, dass diese Arbeit nicht punktuell, sondern systematisch erfolgt: einmal sauber in den Vorlagen umgesetzt, wirkt sie auf allen Seiten, die diese Vorlagen nutzen.

Showcase

So könnte Ihr barrierefreier Auftritt aussehen:

Praxis-WebsiteDemo

Fachärztezentrum

WCAG 2.1 AABFSGSemantisches HTMLBuchung
Corporate WebsiteDemo

Maschinenbau-Unternehmen

MehrsprachigResponsiveKontrasteTastaturbedienung
Restaurant-WebsiteDemo

Restaurant mit Reservierung

Local SEOBarrierefreiReservierungResponsive
Demo
Quellen und Studien

Dieser Beitrag basiert auf Daten und Stellungnahmen aus: WebAIM Million 2025 (Report über die Top-1-Mio.-Startseiten), Overlay Fact Sheet (overlayfactsheet.com), § 37 BFSG (Bußgeldvorschriften, bfsg-gesetz.de), audatis (Overlay-Tools und BFSG), germanupa (BFSG-Prüfung und Overlays) sowie Wikipedia (Web accessibility, AccessiBe). Die genannten Zahlen können je nach Zeitpunkt und Methodik variieren.

In der Regel nicht. Overlays verändern den Quellcode nicht und decken die strukturellen WCAG-Anforderungen meist nur teilweise ab. Maßgeblich ist die tatsächliche Zugänglichkeit Ihres Angebots, die typischerweise eine Umsetzung im Code erfordert.

Das kann vorkommen. Overlays können mit Screenreadern kollidieren, die Tastaturnavigation stören oder ungenaue automatische Beschriftungen liefern. Fachleute weisen darauf hin, dass dadurch neue Barrieren entstehen können.

Nach den Bußgeldvorschriften sind Bußgelder von bis zu 10.000 Euro und in bestimmten Fällen bis zu 100.000 Euro möglich. Die Marktüberwachungsbehörde kann zudem Nachbesserung anordnen und im äußersten Fall das Angebot untersagen (§ 37 BFSG).

Sie umfasst semantisches HTML, eine sinnvolle Überschriftenstruktur, beschriftete Formularfelder, ausreichende Farbkontraste, vollständige Tastaturbedienbarkeit und aussagekräftige Alternativtexte, ausgerichtet an den WCAG-2.1-AA-Kriterien.

Erfahrungsgemäß liefert eine Kombination aus automatisierten Tools und manuellen Prüfungen die belastbarsten Ergebnisse. Dazu gehören Tastaturtests, Screenreader-Prüfungen und idealerweise Rückmeldungen von Menschen, die auf assistive Technologien angewiesen sind.

In der Regel ja. Eine zugängliche Seite erreicht mehr Menschen, verbessert die Bedienbarkeit für alle und wirkt sich oft positiv auf SEO und Conversion aus, weil klare Strukturen allen Besuchern zugutekommen.

Tags:#Barrierefreiheit#BFSG#WCAG#Webentwicklung