Accessibility-Overlays werden als schnelle Lösung für das Barrierefreiheitsstärkungsgesetz (BFSG) beworben: eine Codezeile einbinden, ein Widget erscheint, der Store sei barrierefrei. Diese Vorstellung ist technisch und rechtlich nicht tragfähig. Ein Overlay legt sich als zusätzliche Hilfsoberfläche über Ihre Seite, ändert aber den zugrunde liegenden Quellcode nicht. Genau dieser Quellcode ist es jedoch, an dem die Konformität mit der harmonisierten Norm EN 301 549 v3.2.1 und damit die Anforderung des BFSG gemessen wird. Dieser Beitrag erklärt, was ein Overlay tatsächlich tut, warum es das BFSG nicht erfüllt und welche echten Korrekturen im Shopify-Theme an seine Stelle treten.
Ein Accessibility-Overlay ist ein per JavaScript eingebundenes Skript, das beim Laden der Seite eine zusätzliche Bedienleiste oder ein Symbol einblendet, meist am Bildschirmrand. Über diese Leiste kann der Besucher Anpassungen vornehmen: Schriftgröße ändern, Kontrast erhöhen, Animationen anhalten, einen Vorlesemodus aktivieren. Manche Overlays versuchen darüber hinaus, fehlende Eigenschaften der Seite zur Laufzeit automatisch zu ergänzen, etwa fehlende Alternativtexte oder fehlende Beschriftungen über eine Bilderkennung.
Entscheidend ist, was dabei nicht passiert: Der HTML-Quellcode Ihres Shopify-Themes bleibt unverändert. Das Overlay manipuliert die Seite erst nachträglich im Browser des Besuchers, und nur dort. Es ist eine Schicht über dem Problem, keine Korrektur des Problems. Wenn das Skript nicht lädt, langsam lädt oder mit einer assistiven Technologie in Konflikt gerät, bleibt der ursprüngliche, nicht barrierefreie Code zurück.
Das BFSG (BGBl. 2021 I S. 2970) setzt die EU-Richtlinie 2019/882 (European Accessibility Act, EAA) in deutsches Recht um. Online-Shops fallen nach § 1 Abs. 3 Nr. 5 BFSG als "Dienstleistungen im elektronischen Geschäftsverkehr" in den Anwendungsbereich. Über Anlage I der EU-Richtlinie 2019/882 verweist das BFSG auf die harmonisierte Norm EN 301 549 v3.2.1, die in ihrem Kapitel 9 die WCAG-2.1-AA-Erfolgskriterien für Webinhalte übernimmt.
Die rechtliche Verantwortung trägt nach § 8 BFSG der Diensteanbieter, also der Händler. Das gilt unabhängig davon, ob ein Theme, eine App oder ein Overlay-Anbieter beteiligt ist. Vertraglich kann der Händler gegenüber einem Lieferanten Regress nehmen, gegenüber der Marktüberwachungsbehörde bleibt jedoch der Händler verpflichtet.
Bei Verstößen sieht § 37 BFSG Bußgelder vor. Nach § 37 Abs. 2 BFSG beträgt der Rahmen für das nicht konforme Anbieten oder Erbringen einer Dienstleistung bis zu 100.000 EUR. Das BFSG ist seit dem 28. Juni 2025 für alle Anbieter oberhalb der Kleinstunternehmen-Schwelle anwendbar. Vom Anwendungsbereich ausgenommen sind nach § 3 Abs. 3 BFSG nur Kleinstunternehmen, also Unternehmen mit weniger als zehn Beschäftigten UND einem Jahresumsatz oder einer Jahresbilanzsumme unter zwei Millionen EUR. Beide Bedingungen müssen kumulativ erfüllt sein.
Wichtig zur Einordnung: AccessifyAI hilft, Verstöße zu finden und zu beheben, garantiert aber keine Rechtskonformität oder BFSG-Konformität. Diese Garantie kann kein Werkzeug und kein Overlay seriös geben.
EN 301 549 v3.2.1 und die darin referenzierten WCAG-2.1-AA-Kriterien beschreiben Anforderungen an die Webinhalte selbst, nicht an eine optionale Zusatzoberfläche. Wenn ein Prüfer oder eine Marktüberwachungsbehörde im Beschwerdefall die Konformität bewertet, betrachtet sie die ausgelieferte Seite und ihren Code. Sie prüft, ob Bilder einen Alternativtext im Markup tragen, ob Formularfelder programmatisch mit einer Beschriftung verknüpft sind, ob die Bedienelemente per Tastatur erreichbar sind. Ein Overlay, das diese Eigenschaften nur zur Laufzeit nachzubessern versucht, ändert nichts am gelieferten Code und kann diese Prüfung daher nicht bestehen.
Das zeigt sich an konkreten Kriterien. Drei Beispiele, an denen Overlays regelmäßig nicht das leisten, was das Markup leisten müsste:
| Kriterium |
Anforderung |
Stufe |
| WCAG 1.1.1 Non-text Content |
Bilder brauchen ein textliches Äquivalent |
A |
| WCAG 3.3.2 Labels or Instructions |
Eingabefelder brauchen eine Beschriftung |
A |
| WCAG 4.1.2 Name, Role, Value |
Bedienelemente brauchen programmatisch ermittelbaren Namen und Rolle |
A |
Alle drei sind Stufe A, das niedrigste und damit am striktesten geforderte Konformitätsniveau, und über EN 301 549 v3.2.1 nach dem BFSG verbindlich. Sehen wir uns an, warum die saubere Korrektur im Code liegt und nicht in einer nachträglichen Skript-Schicht.
Ein automatisch generierter Alternativtext aus einer Bilderkennung kann das Motiv beschreiben, aber nicht den Kontext. Ein Produktbild braucht keinen Text wie "Schuh auf weißem Hintergrund", sondern den verkaufsrelevanten Kontext, etwa "Laufschuh Modell Aero in Blau, Seitenansicht". Diese Information steckt in Ihrem Shopify-Produktdatensatz, nicht in der Pixelanalyse eines Overlays.
In Shopify pflegen Sie den Alternativtext direkt am Produktmedium im Admin. Im Theme-Code wird er über das Liquid-Objekt image.alt ausgegeben. Eine korrekte Ausgabe in einer Section sieht so aus:
<img
src="{{ product.featured_image | image_url: width: 800 }}"
alt="{{ product.featured_image.alt | escape }}"
width="800"
height="800"
loading="lazy">
Rein dekorative Bilder, die keine Information tragen, erhalten ein leeres Alternativtext-Attribut, damit ein Screenreader sie überspringt:
<img src="{{ 'divider.svg' | asset_url }}" alt="" role="presentation">
Diese Unterscheidung zwischen informativem und dekorativem Bild trifft ein Overlay nicht zuverlässig. Im Theme-Code treffen Sie sie bewusst und dauerhaft.
Ein Overlay kann ein fehlendes Label nicht im Quellcode ergänzen, es kann es nur im Browser des Besuchers nachträglich zu setzen versuchen, und das auch nur, wenn das Skript fehlerfrei lädt. Die saubere Lösung verknüpft das Eingabefeld direkt im Markup mit seiner Beschriftung. Ein häufiger Fehler in Shopify-Themes ist ein Newsletter- oder Suchfeld, das nur einen Platzhaltertext besitzt. Ein Platzhalter ist kein Label: Er verschwindet bei der Eingabe und wird von assistiven Technologien nicht zuverlässig als Beschriftung erkannt.
Korrekt ist ein <label> mit for-Attribut, das auf die id des Feldes zeigt. Soll das Label visuell nicht erscheinen, blenden Sie es per Technik aus, die es für Screenreader erhält, nicht per display: none:
<form action="/contact#newsletter" method="post">
<label for="newsletter-email" class="visually-hidden">
E-Mail-Adresse für den Newsletter
</label>
<input
type="email"
id="newsletter-email"
name="contact[email]"
autocomplete="email"
required>
<button type="submit">Abonnieren</button>
</form>
Die zugehörige CSS-Klasse visually-hidden versteckt das Label optisch, hält es aber für assistive Technologien zugänglich:
.visually-hidden {
position: absolute;
width: 1px;
height: 1px;
margin: -1px;
padding: 0;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}
Diese Verknüpfung steht fest im ausgelieferten Code und ist damit für jeden Prüfer und jede assistive Technologie verlässlich vorhanden, unabhängig davon, ob ein Skript geladen hat.
Ein häufiges Muster in Themes und Apps ist ein anklickbares <div>, das per JavaScript wie ein Button reagiert. Für die Maus funktioniert das, für Tastatur und Screenreader nicht: Das Element erhält keinen Fokus und meldet weder Rolle noch Name. Ein Overlay kann das nicht grundlegend heilen. Die Korrektur ist ein echtes Button-Element mit klarem, zugänglichem Namen:
<button type="button" class="cart-toggle" aria-label="Warenkorb öffnen">
{% render 'icon-cart' %}
</button>
Trägt ein Icon-Button nur ein Symbol ohne sichtbaren Text, liefert aria-label den programmatisch ermittelbaren Namen, den WCAG 4.1.2 verlangt. Ein natives <button> bringt Fokussierbarkeit und Tastaturbedienung von sich aus mit, ohne zusätzliche Skripte. Das ist robuster als jede nachträgliche Reparatur durch ein Overlay.
Ein Overlay löst nicht nur die bestehenden Probleme nicht, es kann neue schaffen. Das Overlay-Widget selbst ist ein Bedienelement und muss seinerseits den WCAG-Kriterien genügen. Tut es das nicht, fügt es eine weitere Barriere hinzu. Manche Overlays greifen außerdem in die Seite ein und kollidieren mit dem Screenreader oder der Browser-Vergrößerung, die ein Nutzer bereits installiert hat. Menschen, die auf assistive Technologie angewiesen sind, nutzen in der Regel ihre eigene, vertraute Software. Eine aufgesetzte Parallel-Oberfläche, die diese Software stört, verbessert die Situation nicht, sondern verschlechtert sie.
Hinzu kommt ein praktischer Punkt: Lädt das Overlay-Skript langsam, blockiert es das Rendern oder erhöht es die Datenmenge der Seite, kann das die Ladezeit und damit auch die Nutzbarkeit verschlechtern. Eine im Quellcode behobene Seite trägt keine solche Last.
Die deutsche Marktüberwachung ist nach § 32 BFSG dezentral bei den Ländern organisiert. Verfahren werden im Regelfall durch Verbraucherbeschwerden eingeleitet. Wird eine Beschwerde geprüft, ist Gegenstand der Prüfung die tatsächlich ausgelieferte Dienstleistung, also die Seite und ihr Verhalten gegenüber assistiver Technologie. Ein Overlay-Widget am Bildschirmrand ist kein Nachweis von Konformität. Maßgeblich ist, ob die Inhalte selbst die Anforderungen erfüllen.
Nach § 8 BFSG dokumentiert der Diensteanbieter zudem, wie er die Anforderungen erfüllt. Diese Dokumentation stützt sich sinnvoll auf nachvollziehbare Korrekturen im Code, nicht auf die bloße Einbindung eines Drittanbieter-Skripts, dessen Innenleben Sie nicht kontrollieren.
Der tragfähige Weg ist, die Verstöße dort zu beheben, wo sie entstehen: im Liquid- und CSS-Code des Themes, in den Section-Einstellungen und in den Produktdaten. Das bedeutet konkret:
- Alternativtexte an den Produktmedien und in den Section-Einstellungen pflegen, dekorative Bilder mit leerem Alternativtext kennzeichnen (WCAG 1.1.1).
- Formularfelder im Markup mit
<label for> verknüpfen, visuell versteckte Labels per visually-hidden statt display: none (WCAG 3.3.2, 4.1.2).
- Anklickbare
<div>-Elemente durch echte <button>- und <a>-Elemente ersetzen (WCAG 2.1.1, 4.1.2).
- Farbkontraste im Theme über CSS-Variablen anheben, statt sie per Overlay umzufärben (WCAG 1.4.3).
- Den nativen Fokusring erhalten statt per
outline: none zu entfernen (WCAG 2.4.7).
Diese Korrekturen verändern den ausgelieferten Code dauerhaft. Sie sind für jeden Prüfer, jede assistive Technologie und jede Marktüberwachungsbehörde gleichermaßen sichtbar, unabhängig davon, ob ein zusätzliches Skript lädt.
Stellen Sie sich vor einer Kaufentscheidung für ein Werkzeug drei Fragen:
| Frage |
Overlay |
Korrektur im Theme-Code |
| Ändert sich der ausgelieferte Quellcode? |
Nein |
Ja |
| Bleibt die Verbesserung bestehen, wenn das Skript nicht lädt? |
Nein |
Ja |
| Lässt sich die Korrektur dokumentieren und prüfen (§ 8 BFSG)? |
Eingeschränkt |
Ja |
Wenn eine Antwort "Nein" lautet, löst das Werkzeug nicht das Problem, das das BFSG adressiert. Ein Overlay kann allenfalls eine zusätzliche Komfortfunktion für manche Nutzer sein, es ist aber kein Ersatz für barrierefreien Code und kein Nachweis von Konformität.
Verstöße findet man am besten mit Werkzeugen, die den ausgelieferten Code prüfen, ergänzt durch manuelle Tests mit Tastatur und Screenreader. Automatisierte Werkzeuge erfassen nur einen Teil der Kriterien, der Rest erfordert eine manuelle Prüfung.
| Werkzeug |
Zweck |
Kosten |
| axe DevTools |
Erkennt fehlende Alternativtexte, Beschriftungen, ARIA-Probleme |
kostenlose Variante |
| WAVE |
Visuelle Markierung von Verstößen direkt auf der Seite |
kostenlos |
| Lighthouse (Chrome) |
Teilprüfung der Barrierefreiheit |
kostenlos |
| NVDA Screenreader |
Manuelle Prüfung der Sprachausgabe und Bedienung |
kostenlos |
| AccessifyAI |
Shopify-spezifische Überprüfung mit Liquid-Korrekturvorschlägen |
Free-Tier, ab 9,99 USD/Monat |
Welche dieser Verstöße in Ihrem konkreten Store stecken, zeigt nur ein echter Test auf Ihrer aktuellen Theme-Version und im installierten Zustand mit allen aktiven Apps. Ich habe AccessifyAI bewusst ohne Overlay-Ansatz entwickelt: Statt eine Schicht über die Seite zu legen, ordnet das Werkzeug jeden Befund dem Shopify-Code-Modell zu und gibt einen Korrekturvorschlag als Liquid-Diff aus, den Sie vor der Übernahme begutachten und in Ihr Theme übernehmen. So bleibt die Verbesserung im Quellcode und nicht in einem Drittanbieter-Skript. Wenn Sie zunächst nur sehen wollen, wie es um Ihren Store steht, können Sie ohne Installation den kostenlosen On-Page-Scanner auf accessify.ensomedia.pl nutzen. Die App selbst finden Sie im Shopify App Store.
- Prüfen Sie, ob in Ihrem Store ein Overlay aktiv ist, und bewerten Sie es nicht als Konformitätsnachweis.
- Führen Sie einen ehrlichen Test der ausgelieferten Seite mit Tastatur und Screenreader durch.
- Priorisieren Sie die Stufe-A-Verstöße: fehlende Alternativtexte, fehlende Formularbeschriftungen, anklickbare
<div>-Elemente.
- Beheben Sie diese im Theme-Code, nicht über eine aufgesetzte Skript-Schicht.
- Dokumentieren Sie Ihre Maßnahmen nach § 8 BFSG, damit Sie im Beschwerdefall belegen können, wie Sie die Anforderungen erfüllen.
Weitere fachliche Vertiefung finden Sie im Beitrag zu den Unterschieden zwischen BFSG, WCAG und EAA und in unserer BFSG-Pflichtcheckliste mit 14 Punkten.
Nein. Das BFSG misst die Konformität über EN 301 549 v3.2.1 an den Webinhalten selbst, also am ausgelieferten Quellcode. Ein Overlay legt sich nur als zusätzliche Schicht über die Seite und ändert den Code nicht. AccessifyAI und andere Werkzeuge helfen beim Finden und Beheben von Verstößen, eine Konformitätsgarantie kann kein Werkzeug seriös geben. Die Verantwortung trägt nach § 8 BFSG der Händler.
Ein Overlay kann ein Motiv per Bilderkennung beschreiben, aber nicht den verkaufsrelevanten Kontext liefern, der in Ihren Shopify-Produktdaten steckt. WCAG 1.1.1 (Stufe A) verlangt ein passendes textliches Äquivalent. Dieses pflegen Sie zuverlässig am Produktmedium im Admin, ausgegeben über das Liquid-Attribut alt="{{ image.alt }}".
Es kann. Das Overlay-Widget ist selbst ein Bedienelement und muss den WCAG-Kriterien genügen. Manche Overlays kollidieren zudem mit dem Screenreader oder der Vergrößerung, die ein Nutzer bereits einsetzt. Ein zusätzliches Skript kann außerdem die Ladezeit erhöhen. Eine im Quellcode behobene Seite trägt diese Risiken nicht.
Gegenstand der Prüfung ist die tatsächlich ausgelieferte Seite und ihr Verhalten gegenüber assistiver Technologie, nicht ein aufgesetztes Widget. Die Marktüberwachung ist nach § 32 BFSG bei den Ländern organisiert, Verfahren werden in der Regel durch Verbraucherbeschwerden eingeleitet. Maßgeblich ist, ob die Inhalte selbst die Anforderungen erfüllen.
Nach § 37 Abs. 2 BFSG beträgt der Bußgeldrahmen für das nicht konforme Anbieten oder Erbringen einer Dienstleistung bis zu 100.000 EUR. Das BFSG ist seit dem 28. Juni 2025 anwendbar. Die rechtliche Verantwortung trägt nach § 8 BFSG der Diensteanbieter, also der Händler.
Die Verstöße dort beheben, wo sie entstehen: im Liquid- und CSS-Code des Themes, in den Section-Einstellungen und in den Produktdaten. Echte <button>- statt <div>-Elemente, <label for> statt reiner Platzhalter, gepflegte Alternativtexte und ausreichende Farbkontraste. Diese Korrekturen bleiben im ausgelieferten Code bestehen und sind für jeden Prüfer sichtbar.
Ein Accessibility-Overlay ist eine per JavaScript eingebundene Hilfsoberfläche, die den Quellcode Ihres Shopify-Themes nicht verändert. Das BFSG misst die Konformität jedoch über EN 301 549 v3.2.1 an genau diesem Quellcode und den darin enthaltenen WCAG-2.1-AA-Eigenschaften wie Alternativtexten (WCAG 1.1.1), Formularbeschriftungen (WCAG 3.3.2) und programmatisch ermittelbaren Namen von Bedienelementen (WCAG 4.1.2). Ein Overlay kann diese Anforderungen nicht im ausgelieferten Code erfüllen, kann zusätzliche Barrieren schaffen und ist kein Konformitätsnachweis. Der tragfähige Weg sind echte Korrekturen im Theme-Code, die dauerhaft bestehen, für jede assistive Technologie sichtbar sind und sich nach § 8 BFSG dokumentieren lassen. Die rechtliche Verantwortung trägt nach § 8 BFSG der Händler, und kein Werkzeug garantiert Konformität.