Wer für seinen Shopify-Store nach einer Lösung für das Barrierefreiheitsstärkungsgesetz (BFSG) sucht, stößt schnell auf zwei bekannte Marken: accessiBe und UserWay. Beide gehören zur Kategorie der Accessibility-Overlays, also per JavaScript eingebundene Widgets, die sich über die Seite legen und dem Besucher Bedienhilfen wie Schriftvergrößerung oder Kontrastmodus anbieten. Wenn Sie diese Tools kennen, testen oder nach einer Alternative suchen, geht es Ihnen vermutlich um die eigentliche Frage dahinter: Wird mein Store damit den Anforderungen des BFSG gerecht? Dieser Beitrag erklärt den grundlegenden Unterschied zwischen einem Overlay-Widget und einem Scanner, der den Shopify-Quellcode prüft, und zeigt, warum die Korrektur im Theme-Code der tragfähige Weg ist.
accessiBe und UserWay sind Overlay-Anbieter. Ein Overlay ist ein Skript, das beim Laden der Seite eine zusätzliche Bedienleiste einblendet und versucht, einzelne Eigenschaften der Seite zur Laufzeit im Browser des Besuchers nachzubessern. Das ist eine eigene Produktkategorie mit einem klaren Ansatz: eine Schicht über der bestehenden Seite.
AccessifyAI gehört in eine andere Kategorie. Es ist kein Overlay, sondern ein Scanner, der den ausgelieferten Quellcode Ihres Shopify-Themes prüft, jeden Befund einem konkreten WCAG-Erfolgskriterium zuordnet und einen Korrekturvorschlag als Liquid-Diff ausgibt. Statt eine Hilfsoberfläche aufzusetzen, zeigt das Werkzeug, wo im Theme-Code die Barriere liegt, und schlägt vor, wie Sie sie an der Wurzel beheben. Jeden Vorschlag begutachten Sie vor der Übernahme.
Der Unterschied ist also nicht "Anbieter A gegen Anbieter B", sondern "Schicht über dem Code gegen Korrektur im Code". Diese Unterscheidung entscheidet darüber, ob die Verbesserung dort ankommt, wo das BFSG sie misst.
Das BFSG 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 die EU-Richtlinie 2019/882 verweist das BFSG auf die harmonisierte Norm EN 301 549, die in ihrem Webkapitel die WCAG-Erfolgskriterien der Stufe AA übernimmt. Das BFSG ist seit dem 28. Juni 2025 anwendbar.
Maßgeblich ist dabei: EN 301 549 und die darin referenzierten WCAG-Kriterien beschreiben Anforderungen an die Webinhalte selbst, also an das ausgelieferte Markup. 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 ein Bild einen Alternativtext im Markup trägt, ob ein Formularfeld programmatisch mit einer Beschriftung verknüpft ist, ob ein Bedienelement per Tastatur erreichbar ist.
Genau hier liegt der entscheidende Punkt für die Auswahl eines Werkzeugs. Ein Overlay verändert den ausgelieferten Quellcode nicht. Es manipuliert die Seite erst nachträglich im Browser des Besuchers, und nur dort. Lädt das Skript nicht, langsam oder gerät es mit einer assistiven Technologie in Konflikt, bleibt der ursprüngliche, nicht barrierefreie Code zurück. Eine ausführliche Begründung, warum Overlays das BFSG strukturell nicht erfüllen, finden Sie im Beitrag Overlay-Tools und das BFSG: Warum sie keine Lösung sind.
Wichtig zur Einordnung, und das gilt für jedes Werkzeug: AccessifyAI hilft, Barrieren zu finden und zu beheben, garantiert aber keine Rechtskonformität oder BFSG-Konformität. Diese Garantie kann kein Scanner und kein Overlay seriös geben. Die rechtliche Verantwortung trägt der Dienstleistungserbringer, also der Händler, auch dann, wenn der Verstoß auf ein Theme oder eine Drittanbieter-App zurückgeht.
Sehen wir uns an, wie sich der Overlay-Ansatz und der Code-Ansatz an realen WCAG-Anforderungen unterscheiden. Drei Beispiele, jeweils auf Stufe A, dem niedrigsten und damit am striktesten geforderten Konformitätsniveau.
| 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 |
Ein automatisch generierter Alternativtext aus einer Bilderkennung kann das Motiv beschreiben, aber nicht den verkaufsrelevanten Kontext. Ein Produktbild braucht keinen Text wie "Schuh auf weißem Hintergrund", sondern den Kontext, der in Ihrem Shopify-Produktdatensatz steckt, etwa "Laufschuh Modell Aero in Blau, Seitenansicht". Diese Information pflegen Sie am Produktmedium im Admin, und das Theme gibt sie über das Liquid-Objekt image.alt aus:
<img
src="{{ product.featured_image | image_url: width: 800 }}"
alt="{{ product.featured_image.alt | escape }}"
width="800"
height="800"
loading="lazy">
Ein Scanner zeigt Ihnen, welche Bilder im ausgelieferten Code kein passendes Alternativtext-Attribut tragen, und schlägt die Korrektur an dieser Stelle vor. Die Verbesserung bleibt im Quellcode, unabhängig davon, ob ein zusätzliches Skript lädt. Wie Sie Alternativtexte systematisch pflegen, beschreibt der Beitrag Alternativtexte für Produktbilder in Shopify.
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. Die saubere Lösung verknüpft das Feld direkt im Markup mit einem <label> und dessen for-Attribut:
<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>
Diese Verknüpfung steht fest im ausgelieferten Code. Ein Overlay könnte ein fehlendes Label nur zur Laufzeit nachzusetzen versuchen, und das auch nur, wenn das Skript fehlerfrei lädt. Der Code-Ansatz behebt die Ursache.
Ein verbreitetes 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. Die Korrektur ist ein echtes Button-Element mit zugänglichem Namen:
<button type="button" class="cart-toggle" aria-label="Warenkorb öffnen">
{% render 'icon-cart' %}
</button>
Ein natives <button> bringt Fokussierbarkeit und Tastaturbedienung von sich aus mit. Ein Scanner, der den Code prüft, erkennt das anklickbare <div> und verweist auf die korrekte Auszeichnung. Das ist robuster als jede nachträgliche Reparatur durch ein Skript.
Drei Gründe machen die Korrektur im Theme-Code zum belastbaren Weg, wenn es um das BFSG geht.
Erstens: Die Prüfung greift auf den Code zu. Im Beschwerdefall betrachtet die Marktüberwachung die tatsächlich ausgelieferte Seite und ihr Verhalten gegenüber assistiver Technologie, nicht ein aufgesetztes Widget. Ein Overlay-Symbol am Bildschirmrand ist kein Nachweis von Konformität. Maßgeblich ist, ob die Inhalte selbst die Anforderungen erfüllen.
Zweitens: Die Verbesserung ist dokumentierbar. Nach § 14 BFSG erstellt und veröffentlicht der Dienstleistungserbringer Informationen darüber, wie die Dienstleistung die Anforderungen erfüllt, mit dem Inhalt nach Anlage 3 BFSG. Auf Verlangen der Marktüberwachungsbehörde legt er nach § 14 Abs. 5 BFSG die nötigen Unterlagen vor. Eine nachvollziehbare Korrektur im Liquid-Code, mit Datum und betroffenem Kriterium, lässt sich belegen. Die bloße Einbindung eines Drittanbieter-Skripts, dessen Innenleben Sie nicht kontrollieren, lässt sich schwerer dokumentieren.
Drittens: Die Korrektur schafft keine neuen Barrieren. Das Overlay-Widget ist selbst ein Bedienelement und muss seinerseits den WCAG-Kriterien genügen. Manche Overlays kollidieren zudem mit dem Screenreader oder der Vergrößerung, die ein Nutzer bereits einsetzt. Eine im Quellcode behobene Seite trägt dieses Risiko nicht und erhöht auch nicht die Ladelast durch ein zusätzliches Skript.
Ehrlichkeit gehört zur Auswahl dazu. Ein automatisierter Scanner erfasst nur einen Teil der WCAG-Kriterien, der Rest erfordert eine manuelle Prüfung mit Tastatur und Screenreader. Ein Scanner findet zuverlässig fehlende Alternativtexte, fehlende Formularbeschriftungen, anklickbare <div>-Elemente oder unzureichende Farbkontraste. Er kann aber nicht beurteilen, ob ein vorhandener Alternativtext inhaltlich passt oder ob eine Bedienlogik für einen Screenreader-Nutzer wirklich verständlich ist. Diese Lücke schließt kein Werkzeug, weder Overlay noch Scanner. Wie Sie die manuelle Seite ergänzen, zeigt der Beitrag Screenreader-Test für Shopify mit NVDA.
Der praktische Vorteil eines Scanners gegenüber einem Overlay liegt nicht in einer angeblichen Vollständigkeit, sondern darin, dass er die Befunde dort verortet, wo die Korrektur stattfindet: im Code. Sie sehen, was zu tun ist, übernehmen den Vorschlag in Ihr Theme und behalten die Kontrolle über jede Änderung.
| Frage |
Overlay (z. B. accessiBe, UserWay) |
Code-Scanner (AccessifyAI) |
| Ändert sich der ausgelieferte Quellcode? |
Nein |
Ja, durch übernommene Liquid-Korrekturen |
| Bleibt die Verbesserung bestehen, wenn das Skript nicht lädt? |
Nein |
Ja |
| Lässt sich die Korrektur dokumentieren (§ 14 BFSG)? |
Eingeschränkt |
Ja |
| Kann ein neues Bedienelement zusätzliche Barrieren schaffen? |
Möglich |
Nein |
Wenn eine Antwort in der linken Spalte "Nein" oder "Eingeschränkt" lautet, adressiert das Werkzeug nicht das, woran das BFSG die Konformität misst. Ein Overlay kann allenfalls eine zusätzliche Komfortfunktion für manche Nutzer sein, es ist aber kein Ersatz für barrierefreien Code.
Die Kosten einer präventiven Überprüfung liegen deutlich unter den Kosten einer Beanstandung. Nach § 37 BFSG reicht der Bußgeldrahmen für das nicht konforme Erbringen einer Dienstleistung bis zu 100.000 EUR pro Verstoß, wobei dies eine Obergrenze ist und kein Regelsatz. Hinzu kommt das oft schneller spürbare Risiko einer wettbewerbsrechtlichen Abmahnung über das UWG. Eine genaue Einordnung dieser Größenordnungen finden Sie im Beitrag BFSG-Bußgelder im Shopify-Kontext.
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 von höchstens zwei Millionen EUR. Beide Bedingungen müssen kumulativ erfüllt sein. Ob diese Ausnahme für Sie greift, klärt der Beitrag BFSG-Ausnahme für Kleinstunternehmen im Shopify-Kontext. Das BFSG ist seit dem 28. Juni 2025 für alle Anbieter oberhalb dieser Schwelle anwendbar.
Welche Barrieren in Ihrem konkreten Store stecken, zeigt nur ein echter Test auf Ihrer aktuellen Theme-Version, im installierten Zustand mit allen aktiven Apps. Wenn Sie zunächst nur sehen wollen, wie es um Ihre Startseite steht, nutzen Sie den kostenlosen Scan Ihrer Startseite ohne Installation. AccessifyAI ordnet dabei jeden Befund einem WCAG-Kriterium zu und gibt einen Korrekturvorschlag als Liquid-Diff aus, den Sie vor der Übernahme begutachten. Die App selbst, mit der Sie alle Seiten Ihres Stores prüfen, finden Sie im Shopify App Store, mit kostenlosem Einstieg und kostenpflichtigen Plänen für mehr Funktionen.
Diese Einordnung trifft der Beitrag nicht. accessiBe und UserWay gehören zur Kategorie der Overlays, also zu Werkzeugen, die sich als Schicht über die Seite legen. Der Punkt ist kategorisch: Ein Overlay ändert den ausgelieferten Quellcode nicht, und genau an diesem Quellcode misst das BFSG über EN 301 549 die Konformität. Wer das BFSG adressieren will, braucht Korrekturen im Theme-Code.
Ein Scanner, der den ausgelieferten Code Ihres Themes prüft, jeden Befund einem WCAG-Kriterium zuordnet und konkrete Korrekturen vorschlägt, die Sie in Ihr Theme übernehmen. AccessifyAI arbeitet nach diesem Ansatz und gibt die Korrekturen als Liquid-Diff aus, den Sie vor der Übernahme begutachten. So bleibt die Verbesserung im Quellcode statt in einem Drittanbieter-Skript.
Nein, und kein Werkzeug sollte das behaupten. AccessifyAI hilft, Barrieren zu finden und zu beheben, garantiert aber keine Rechtskonformität. Ein automatisierter Scan erfasst zudem nur einen Teil der WCAG-Kriterien, der Rest erfordert eine manuelle Prüfung. Die Verantwortung trägt als Dienstleistungserbringer der Händler.
Weil das BFSG die Konformität über EN 301 549 an den Webinhalten selbst misst, also am ausgelieferten Markup. Ein Overlay manipuliert die Seite nur nachträglich im Browser des Besuchers und ändert den Code nicht. Lädt das Skript nicht oder gerät es mit assistiver Technologie in Konflikt, bleibt der nicht barrierefreie Code zurück. Im Beschwerdefall betrachtet die Marktüberwachung den ausgelieferten Code, nicht das Widget.
Ja. Sie können das Overlay-Skript deaktivieren und stattdessen die Barrieren im Theme-Code beheben. Ein Scanner zeigt Ihnen, wo diese Barrieren liegen. Beginnen Sie mit den Stufe-A-Verstößen, also fehlenden Alternativtexten, fehlenden Formularbeschriftungen und anklickbaren <div>-Elementen, und dokumentieren Sie Ihre Maßnahmen entlang der Informationspflicht nach § 14 BFSG.
accessiBe und UserWay stehen für die Kategorie der Accessibility-Overlays, also Widgets, die sich als Schicht über die Seite legen, ohne den Quellcode zu ändern. Das BFSG misst die Konformität jedoch über EN 301 549 an genau diesem Quellcode und den darin enthaltenen WCAG-Eigenschaften wie Alternativtexten (WCAG 1.1.1), Formularbeschriftungen (WCAG 3.3.2) und programmatisch ermittelbaren Namen von Bedienelementen (WCAG 4.1.2). Die kategorisch andere Alternative ist ein Scanner, der den Theme-Code prüft und konkrete Liquid-Korrekturen vorschlägt, die Sie vor der Übernahme begutachten. Diese Korrekturen bleiben im ausgelieferten Code bestehen, sind für jede assistive Technologie und jeden Prüfer sichtbar und lassen sich entlang der Pflichten nach § 14 BFSG dokumentieren. Kein Werkzeug garantiert Rechtskonformität, und ein automatisierter Scan ersetzt nicht die manuelle Prüfung. Aber für das BFSG ist die Korrektur im Code der tragfähige Weg, nicht die Schicht darüber.