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.
Zwei verschiedene Kategorien, kein direkter Vergleich
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.
Wo das BFSG die Konformität 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.
Der Unterschied an drei konkreten Kriterien
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 |
Alternativtexte (WCAG 1.1.1)
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.
Formularbeschriftungen (WCAG 3.3.2)
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.
Echte Bedienelemente (WCAG 4.1.2)
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.