BFSG-Overlay im Shopify-Shop: Warum ein Widget nicht reicht

Eine Zeile JavaScript, 59 $ im Monat, Barrierefreiheit abgehakt — so klingt das Versprechen der Barrierefreiheits-Overlays für den Shopify-Shop. Die US-Handelsbehörde FTC hat dieses Versprechen geprüft und im April 2025 final angeordnet, dass der bekannteste Anbieter accessiBe 1 Mio. US-Dollar zahlt — wegen irreführender Werbeaussagen, das Widget mache Websites WCAG-konform, und wegen nicht als bezahlt gekennzeichneter Bewertungen.

Das heißt nicht, dass Overlay-Widgets nutzlos sind — sie leisten nur etwas anderes, als ihre Werbung nahelegt. In diesem Artikel zerlege ich das Thema technisch: was ein Overlay im Shopify-Theme tatsächlich tut, warum die Automatik nur einen Bruchteil der Barrieren findet, welche vier Baustellen Theme-Arbeit bleiben, wann ein Widget trotzdem vertretbar ist — und wie Sie die Basics selbst prüfen.

Vorab die übliche Klarstellung: Ich bin Shopify-Entwickler, kein Anwalt. Dieser Artikel behandelt die technische Seite. Ob das Barrierefreiheitsstärkungsgesetz (BFSG) Ihren Shop überhaupt verpflichtet, ist eine Rechtsfrage für Anwalt, Händlerbund oder IT-Recht Kanzlei.

Was das BFSG verlangt — und warum das hier ein Technik-Artikel bleibt

Das Barrierefreiheitsstärkungsgesetz ist am 28. Juni 2025 in Kraft getreten und betrifft unter anderem den elektronischen Geschäftsverkehr — also Onlineshops. Seit August 2025 sind erste Abmahnungen mit BFSG-Bezug dokumentiert, im bekannt gewordenen Fall mit einer Forderung von 1.032,44 €.

Wichtig für die Einordnung: § 2 Nummer 17 BFSG definiert Kleinstunternehmen (weniger als zehn Beschäftigte, höchstens 2 Mio. € Jahresumsatz oder Bilanzsumme), und § 3 Absatz 3 BFSG nimmt solche Unternehmen bei Dienstleistungen von den Anforderungen aus.

Unabhängig von der Rechtsfrage: Technischer Prüfmaßstab sind die Web Content Accessibility Guidelines (WCAG), und Shopify pflegt dazu eine eigene Accessibility-Doku für Themes — mit Empfehlungen zu Skip-Links, Fokus-Zuständen, Tastaturbedienung, Kontrasten und ARIA. An beiden orientiert sich alles Folgende.

Was ein Barrierefreiheits-Overlay technisch wirklich tut

Die Installation ist bei allen Anbietern ähnlich: Die App fügt ein App-Embed hinzu (sichtbar unter Onlineshop → Themes → Anpassen → App-Embeds), das ein JavaScript vom CDN des Anbieters nachlädt. Der Theme-Code bleibt unangetastet — das ist der Kern des Modells und zugleich seine Grenze.

Das nachgeladene Script macht zwei sehr unterschiedliche Dinge:

1. Eine Bedienungs-Toolbar einblenden. Besucher können Schriftgröße erhöhen, einen Kontrast-Modus aktivieren, Animationen pausieren. Ein echter Komfort-Layer — der aber nur denen hilft, die das Widget finden und bedienen können.
2. Das DOM zur Laufzeit heuristisch nachbessern. Das Script rät per Bilderkennung Alt-Texte, injiziert ARIA-Attribute in Elemente, die es für Buttons oder Menüs hält, und hängt Tastatur-Handler an. Auf diesem Teil ruhen die „automatisch konform“-Versprechen.

Für Shopify konkret: Das bekannteste accessiBe accessWidget kostet laut App-Store-Listing 59, 179 oder 479 $ pro Monat, bei 3,9 von 5 Sternen (16 Reviews, Stand August 2026). Die Aufgaben-Verteilung im Überblick:

Nebeneffekt: Ein Overlay ist ein weiteres Third-Party-Script auf jeder Seite — ein bekanntes Thema aus der Performance-Optimierung.

Die Grenze der Automatik: 17 bis 41 Prozent

Warum kann ein Script nicht einfach „alles reparieren“? Weil es die meisten Barrieren gar nicht erst erkennt. Der britische Government Digital Service hat eine Testseite mit absichtlich eingebauten Barrieren gebaut und automatische Prüf-Tools darauf angesetzt: Das beste Tool fand 37 bis 41 % der Barrieren, das schlechteste 17 %.

Die Logik dahinter ist unbestechlich: Was die Automatik nicht erkennt, kann sie auch nicht reparieren. Maschinell prüfbar ist Formales — fehlt ein Alt-Attribut, fehlt ein Formular-Label. Nicht maschinell entscheidbar ist Inhaltliches: ob der geratene Alt-Text das Produkt sinnvoll beschreibt, ob die Fokus-Reihenfolge der visuellen Logik folgt, ob eine Fehlermeldung verständlich ist. Ein Overlay operiert vollständig innerhalb dieser Automatik-Grenze.

Die FTC-Anordnung von April 2025 ist deshalb technisch folgerichtig: Beanstandet wurde nicht das Produkt an sich, sondern die Werbeaussage, es mache Websites WCAG-konform. Genau diese Erwartung sollten Sie an kein Widget richten.

Was kein Overlay kann: vier Baustellen im Shopify-Theme

1. Kontraste der Standard-Ansicht

WCAG 2.1 verlangt auf Level AA ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text — und zwar in der Ansicht, die jeder Besucher standardmäßig sieht, nicht in einem Kontrast-Modus, den man erst per Widget-Klick aktiviert. Der Fix liegt im Customizer (Onlineshop → Themes → Anpassen → Theme-Einstellungen → Farben), für den Checkout separat unter Einstellungen → Checkout → Anpassen.

2. Fokus-Reihenfolge

Wer mit Tab navigiert, folgt der DOM-Reihenfolge — nicht der visuellen Anordnung. Springt der Fokus vom Header in den Footer und erst dann in die Produktinfos, liegt das an der Section-Struktur und an fehlendem Fokus-Management in Drawern und Modals (landet der Fokus beim Öffnen im Warenkorb-Drawer, kehrt er nach Esc zum Button zurück?). Ein nachgeladenes Script kann die DOM-Struktur nicht sinnvoll umbauen — das ist Arbeit in den Section- und Snippet-Dateien.

3. ARIA-Attribute

Shopifys Accessibility-Doku empfiehlt gezielte ARIA-Attribute: aria-expanded und aria-controls an aufklappbaren Menüs, aria-live für dynamische Änderungen wie den Warenkorb-Zähler, aria-describedby an Formularfehlern. Der Punkt ist das Wort gezielt: Korrektes ARIA setzt voraus, dass man die Logik der Komponente kennt. Ein Overlay, das Elemente per Heuristik klassifiziert, injiziert zwangsläufig auch falsche Attribute — und falsches ARIA führt Screenreader-Nutzer aktiver in die Irre als gar keins.

4. Tastaturbedienung

Varianten-Auswahl, Mega-Menü, Quick-View-Modal, Warenkorb-Drawer: Shopify empfiehlt, dass all das komplett per Tastatur bedienbar ist — Tab und Shift+Tab zum Navigieren, Enter oder Leertaste zum Öffnen, Esc zum Schließen. Das steckt in der Event-Behandlung der Theme-Komponenten. Zwei Basics sind in jedem Theme nachrüstbar — Skip-Link und sichtbarer Fokus-Ring (Code-Zugang: Onlineshop → Themes → ⋯ → Code bearbeiten):

{% comment %} Skip-Link: erster Tab-Stopp der Seite {% endcomment %}
<a class="skip-to-content-link" href="#MainContent">
  Zum Seiteninhalt springen
</a>

/* Fokus-Ring niemals global entfernen — ohne ihn ist der Shop
   für Tastatur-Nutzer blind zu steuern */
:focus-visible {
  outline: 0.2rem solid currentColor;
  outline-offset: 0.3rem;
}
 
/* Skip-Link: unsichtbar, bis er per Tab fokussiert wird */
.skip-to-content-link {
  position: absolute;
  left: -9999px;
}
.skip-to-content-link:focus {
  left: 1rem;
  top: 1rem;
  z-index: 100;
}

Das #MainContent-Ziel existiert in modernen OS-2.0-Themes meist schon als ID des main-Elements; falls nicht, ergänzen Sie dort id="MainContent" und tabindex="-1" — wie Sections und Snippets zusammenspielen, zeigt der Sections-Everywhere-Guide.

Ehrlicher Entscheidungsbaum: Wann ist ein Widget vertretbar?

Overlays pauschal zu verteufeln wäre so unehrlich wie das Konformitäts-Versprechen der Anbieter. Vier Fragen entscheiden:

1. Ist Ihr Theme in den Basics solide — Tastatur-Rundgang funktioniert, Fokus sichtbar, Kontraste erfüllen die WCAG-Werte? Dann ist ein Widget als Zusatz-Komfort vertretbar: Es ergänzt eine zugängliche Basis, statt eine unzugängliche zu kaschieren.
2. Erwarten Sie vom Widget „Konformität auf Knopfdruck“? Diese Erwartung hat die FTC als irreführend eingestuft — und der GDS-Test erklärt warum: Die Automatik findet bestenfalls 37 bis 41 % der Barrieren. Als Allein-Lösung überdeckt das Widget die Baustellen, statt sie zu beheben.
3. Rechnet sich das Abo gegen einmalige Theme-Arbeit? 59 bis 479 $ pro Monat sind 708 bis 5.748 $ pro Jahr — ohne dass sich am Theme etwas verbessert. Kontrast-Korrekturen, Fokus-Ring, Skip-Link und ARIA-Fixes sind einmalige Eingriffe.
4. Nutzen Sie das Widget als Übergang? Als Zusatzmaßnahme, während die Theme-Remediation läuft, vertretbar — mit Enddatum und dem klaren Verständnis, dass es sie nicht ersetzt.

Manuelle Basics: die Barrierefreiheits-Checkliste fürs Theme

Sechs Prüfschritte, die kein Widget für Sie erledigt — Sie brauchen nur Browser und Tastatur.

1. Tastatur-Rundgang durch den Kaufprozess

   Maus weglegen, nur mit Tab, Shift+Tab, Enter und Esc navigieren: Startseite, Hauptmenü, Produktseite mit Varianten-Auswahl, Warenkorb, Checkout-Start. Jede Stelle, an der der Fokus verschwindet oder unlogisch springt, kommt auf die Fix-Liste.

2. Fokus-Ring sichtbar machen

   Im Theme-CSS (Onlineshop → Themes → ⋯ → Code bearbeiten) nach outline: none und outline: 0 suchen. Jede Fundstelle ohne gleichwertigen Ersatz-Fokus-Stil ist ein Befund — der Fix ist der :focus-visible-Block aus dem Code-Beispiel oben.

3. Kontraste gegen die WCAG-Werte prüfen

   Fließtext, Preise, Buttons und Formular-Hinweise gegen 4,5:1 (normaler Text) bzw. 3:1 (großer Text) prüfen — die Browser-DevTools zeigen das Verhältnis beim Inspizieren direkt an. Korrekturen im Customizer unter Theme-Einstellungen → Farben, für den Checkout unter Einstellungen → Checkout → Anpassen.

4. Alt-Texte redaktionell pflegen

   Produktbilder: Produkte → Produkt → Medien → Alt-Text bearbeiten. Beschreiben Sie, was für die Kaufentscheidung relevant ist, statt Keywords zu stapeln. Bei großen Sortimenten gesammelt per Produkt-CSV (Spalte Image Alt Text) oder automatisiert per Flow oder Mechanic.

5. Formulare mit echten Labels ausstatten

   Kontaktformular, Newsletter, Suche: Jedes Eingabefeld braucht ein korrekt verknüpftes label-Element — ein Platzhalter-Text allein verschwindet beim Tippen. Fehlermeldungen gehören per aria-describedby ans Feld.

6. Struktur-Stichprobe mit Screenreader

   Eine Produktseite mit einem Screenreader öffnen (NVDA unter Windows, VoiceOver auf dem Mac): Ist die Überschriften-Hierarchie logisch, gibt es genau eine H1, führt der Skip-Link zum Inhalt? Fünf Minuten Stichprobe zeigen mehr reale Probleme als jeder Automatik-Report.

Fazit: Ein Widget ist ein Zusatz, kein Ersatz

Der technische Befund ist eindeutig: Ein Barrierefreiheits-Overlay ändert nichts am Theme-Code — und genau dort liegen die entscheidenden Barrieren. Die Automatik findet bestenfalls 37 bis 41 % der Probleme, das prominenteste Konformitäts-Versprechen der Branche endete in einer 1-Mio.-$-Anordnung der FTC. Kontraste, Fokus, ARIA und Tastaturbedienung bleiben manuelle Arbeit in CSS, Liquid und Komponenten-JavaScript.

Mein Rat: Gehen Sie zuerst die sechs Basics-Checks oben durch — ein Nachmittag Aufwand, eine ehrliche Fix-Liste. Ein Widget können Sie danach immer noch als Komfort-Ergänzung bewerten, in Kenntnis dessen, was es leistet und was nicht. Ob das BFSG Ihren Shop verpflichtet, klären Sie parallel mit Anwalt oder Händlerbund. Und wenn Sie den Ist-Zustand systematisch erhoben haben wollen: Im technischen Compliance-Audit für 490 € prüfe ich die Barrierefreiheits-Basics zusammen mit den übrigen Pflicht-Baustellen — von Grundpreisen bis GPSR — mit priorisiertem Prüfbericht statt Bauchgefühl.

Häufige Fragen

Weiterführende Artikel

• Abmahnung im Onlineshop: die technische Checkliste – Der Gesamtkatalog der technischen Pflicht-Baustellen, in dem Barrierefreiheit ein Prüfpunkt von zehn ist.
• GPSR im Shopify-Shop: Pflichtangaben richtig anzeigen – Der zweite große Compliance-Baustein: Pflichtangaben strukturiert erfassen und auf der Produktseite rendern.
• Shopify-Performance-Optimierung – Warum jedes Third-Party-Script zählt — auch ein Overlay-Widget lädt auf jeder Seite mit.