Barrierefreiheit mit Shopware

Shopware trifft die Anforderungen härter als ein Content-System, weil ein Shop ausdrücklich zu den vom BFSG erfassten Dienstleistungen zählt. Die gute Nachricht: Die Storefront von Shopware 6 ist ein serverseitig gerendertes Twig-Template auf Bootstrap-Basis – jede Zeile Markup lässt sich überschreiben. Die schlechte: Genau deshalb liegt die Verantwortung vollständig bei deinem Projekt.

Das Wichtigste in Kürze

• Onlineshops sind als Dienstleistungen im elektronischen Geschäftsverkehr vom BFSG namentlich erfasst – seit dem 28. Juni 2025, technischer Maßstab ist WCAG Stufe AA über die EN 301 549.
• Die Shopware-6-Storefront rendert serverseitig mit Twig und setzt auf Bootstrap auf. Jeder Block ist über ein eigenes Theme überschreibbar; du bist damit nicht auf Anbieter-Updates angewiesen.
• Die vier kritischen Strecken eines Shops sind immer dieselben: Produktfilter, Variantenauswahl, Warenkorb und Checkout. Sie entscheiden über Kauf oder Abbruch.
• Erlebniswelten (Shopping Experiences) sind der Shopware-eigene Page-Builder. Sie erlauben freie Layouts – und damit auch Überschriftenebenen, die nicht zur Struktur passen. Redaktionsregeln sind hier wichtiger als Code.
• Zahlungs- und Versandarten sind meist Plugins von Drittanbietern und bringen eigenes Markup mit. Sie liegen ausgerechnet auf der letzten Meile des Checkouts.
• Kleinstunternehmen – weniger als 10 Beschäftigte und höchstens 2 Mio. € Umsatz oder Bilanzsumme – sind bei Dienstleistungen ausgenommen (§ 3 Absatz 3 BFSG). Für eigene Produkte im Sinne des Gesetzes gilt die Ausnahme nicht.
• Stand August 2026 gibt es kein Theme und kein Plugin, das einen Shopware-Shop automatisch konform macht. Geprüft wird die ausgelieferte Seite.

Kein Rechtsrat. Ob dein Shop erfasst ist, hängt von Angebot und Unternehmensgröße ab. Der BFSG-Schnelltest klärt die Systematik, den Einzelfall klärt eine juristische Prüfung.

Warum ein Shop der schärfere Fall ist

Bei einer Informationsseite lässt sich über den Anwendungsbereich streiten. Bei einem Shop nicht: Wer Verbrauchern etwas verkauft, erbringt eine Dienstleistung im elektronischen Geschäftsverkehr, und die steht im Gesetz. Dazu kommt eine praktische Verschärfung – ein Shop ist kein Lesevorgang, sondern eine Kette von Handlungen. Bricht eine davon, ist der gesamte Vorgang wertlos. Ein Produktbild ohne Alt-Text ist ärgerlich; ein Zahlartenwähler, der sich nicht mit der Tastatur bedienen lässt, beendet den Kauf.

Was in Shops technisch zu tun ist, steht ausführlich unter Barrierefreiheit in Onlineshops. Diese Seite ergänzt, was Shopware daran besonders macht.

Die Storefront: Twig statt Blackbox

Der wichtigste strukturelle Vorteil von Shopware 6 gegenüber gehosteten Systemen ist banal und wirkt sich massiv aus: Das Frontend wird serverseitig aus Twig-Templates gerendert, und du kannst jeden Block in einem eigenen Theme überschreiben, ohne den Kern zu verändern.

Ein Versionsdetail, das im Bestand oft übersehen wird: Shopware hat mit 6.6 eine Reihe von Verbesserungen am Standard-Theme eingeführt – unter anderem an Tastaturbedienung, Fokusdarstellung und Paginierung – die dort zunächst nur hinter dem Feature-Flag ACCESSIBILITY_TWEAKS aktiv sind. Ab 6.7 sind sie standardmäßig eingeschaltet. Stand August 2026 heißt das für Shops auf 6.6: Wer das Flag nie gesetzt hat, läuft ohne diese Verbesserungen, obwohl sie im Code liegen. Ein Blick in die .env-Datei klärt das in einer Minute.

Praktisch heißt das: Wenn ein Bedienelement die falsche Rolle hat, ein Label fehlt oder ein Icon-Button keinen Namen trägt, ist das ein Template-Override und kein Ticket beim Hersteller. Diese Reparaturen liegen dort, wo sie hingehören – einmal im Template statt Seite für Seite.

Was ich mir dabei zuerst ansehe:

• Icon-Buttons. Warenkorb, Suche, Merkzettel und Menü sind häufig reine Symbole. Sie brauchen einen zugänglichen Namen; wie der entsteht, regelt 4.1.2 Name, Rolle, Wert.
• Der Fokusring. Bootstrap bringt einen mit, Custom-Themes entfernen ihn gern. Ein Ring mit 3:1 Kontrast ist Pflicht (2.4.7).
• Off-Canvas-Elemente. Menü und Warenkorb fahren als Overlay ein. Sie müssen den Fokus aufnehmen, mit Esc schließen und ihn danach zurückgeben – das Muster steht unter Dialoge und Modals.
• Die Überschriftenkette der Kategorieseite. Kategoriename, Filterüberschriften und Produktnamen konkurrieren dort um Ebenen.

Filter, Varianten, Warenkorb, Checkout

Produktfilter. Shopware aktualisiert die Trefferliste ohne Neuladen. Genau das ist die Stelle, an der eine Live-Region gebraucht wird: Wer die Zahl nicht sieht, muss sie hören – „24 Ergebnisse“. Ohne Ansage bleibt unklar, ob der Klick etwas bewirkt hat.

Variantenauswahl. Farb- und Größenfelder sind semantisch eine Auswahlgruppe, kein Beiwerk. Farbfelder brauchen einen Textnamen, nicht nur einen Farbpunkt – sonst hängt die Bedeutung allein an der Farbe und verstößt gegen 1.4.1. Nicht verfügbare Varianten müssen als solche erkennbar sein, nicht nur ausgegraut.

Warenkorb. Mengenänderungen sind der häufigste Ort für stumme Aktualisierungen. Der neue Gesamtpreis gehört angesagt, das Entfernen eines Artikels bestätigt.

Checkout. Die Anforderungen verschärfen sich hier, weil ein Fehler Geld kostet. 3.3.4 Fehlervermeidung verlangt für rechtlich bindende Vorgänge eine Prüf- oder Korrekturmöglichkeit vor dem Absenden – die Bestellübersicht erfüllt das, wenn sie erreichbar und änderbar ist. Dazu kommt 3.3.7 Redundante Eingabe: Die Rechnungsadresse darf nicht ein zweites Mal getippt werden müssen.

Suchergebnis und Produktkacheln

Ein Detail, das in Shopware-Projekten regelmäßig übersehen wird, weil es optisch unauffällig ist: die Struktur der Produktkachel. Jede Kachel enthält Bild, Titel, Preis, Bewertung und eine Schaltfläche – und diese fünf Elemente konkurrieren um Bedeutung.

Drei Punkte entscheiden hier über die Bedienbarkeit:

• Der Produkttitel ist die Überschrift der Kachel, typischerweise eine Ebene unter der Sektionsüberschrift. Wer jeden Titel als h2 auszeichnet, erzeugt auf einer Kategorieseite dreißig gleichrangige Überschriften ohne Gliederung.
• Der ganze Kachelinhalt sollte nicht dreimal verlinkt sein. Bild, Titel und Schaltfläche zeigen oft auf dieselbe URL – im Tastaturdurchlauf sind das drei Stopps für ein Produkt. Das Muster dafür steht unter Klickbare Cards.
• Die Bewertung braucht einen Textwert. Fünf Sternsymbole ohne Zahl sind für Hilfsmittel entweder stumm oder ein Zeichensalat; „4,2 von 5 Sternen“ als Text löst es.

Dasselbe gilt für die Suchergebnisseite, ergänzt um die Trefferzahl: Sie gehört als Text ausgegeben und bei Änderung angesagt.

Erlebniswelten: der Page-Builder im Shop

Shopping Experiences sind komfortabel und erzeugen dieselbe Klasse von Problemen wie jeder Page-Builder. Drei Regeln haben sich bei mir bewährt:

1. Überschriftenebene ist Struktur, nicht Schriftgröße. Im Text-Element wird die Ebene bewusst gesetzt; Optik macht das Theme. Hintergrund unter Überschriften-Hierarchie.
2. Kein Text in Bildern. Aktionsbanner mit eingebranntem Preis sind bequem und verstoßen gegen 1.4.5. Text gehört als Text über das Bild gelegt.
3. Slider nur mit Bedienelementen. Automatisch wechselnde Bühnen brauchen eine Pause-Schaltfläche (2.2.2).

Plugins auf der letzten Meile

Zahlungsdienstleister, Versanddienste, Consent-Werkzeuge und Bewertungssysteme bringen eigenes Markup und eigenes JavaScript mit – und sitzen ausgerechnet dort, wo der Kauf entschieden wird. Zwei Punkte, die ich vor jeder Plugin-Entscheidung kläre:

• Wird im eigenen Frontend gerendert oder in einem iframe eines Dritten? Bei einem iframe endet dein Einfluss an dessen Rand; du brauchst dann eine Zusage des Anbieters und im Zweifel eine Alternative.
• Gibt es eine Konformitätsaussage? Bei europäischen Anbietern ist eine Erklärung zur EN 301 549 inzwischen eine faire Frage im Auswahlprozess – die Barrierefreiheitserklärung deines Shops muss am Ende auch diese Bausteine abdecken.

Der Consent-Banner verdient eine eigene Erwähnung, weil er vor allem anderen liegt: Cookie-Banner.

So prüfst du deinen Shopware-Shop

1. Kaufe bei dir selbst – nur mit der Tastatur. Von der Startseite über Kategorie, Filter, Produkt, Warenkorb bis zur Bestellbestätigung. Was du nicht schaffst, schafft niemand.
2. Wiederhole den Kauf bei 400 % Zoom. Kategorieraster und Checkout-Spalten sind die typischen Reflow-Brecher.
3. Setze einen Filter und höre auf die Trefferzahl. Kommt eine Ansage?
4. Sende das Adressformular absichtlich unvollständig ab. Steht der Fehler am Feld, im Klartext, und springt der Fokus dorthin?
5. Prüfe die Variantenauswahl ohne Farbwahrnehmung – Graustufen-Emulation in den DevTools. Bleibt erkennbar, was gewählt und was nicht verfügbar ist?
6. Bediene Off-Canvas-Menü und Mini-Warenkorb per Tastatur, inklusive Esc.
7. Lass axe DevTools auf Kategorie-, Produkt- und Checkout-Seite laufen und trenne die Befunde nach Theme, Erlebniswelt und Plugin.

Der übergreifende Ablauf steht unter Barrierefreiheit selbst testen.

Häufiger Fehler in der Praxis

Nur die Startseite geprüft. Sie ist die am besten gepflegte Seite des Shops und die mit der geringsten rechtlichen Bedeutung. Der Checkout entscheidet.

Das Theme aktualisiert, die Overrides vergessen. Wer Template-Blöcke überschreibt, muss sie nach größeren Shopware-Updates gegenprüfen – sonst fällt eine Reparatur unbemerkt weg oder doppelt sich.

Barrierefreiheit an die Agentur delegiert, ohne sie zu beauftragen. Sie steht selten im Leistungsverzeichnis. Wenn sie nicht ausgeschrieben ist, wird sie nicht gebaut – und Nachrüsten kostet ein Vielfaches.

Die Bestellbestätigung vergessen. Bestätigungsseite und Bestell-E-Mail gehören zum Vorgang. Eine E-Mail, die nur aus einer Bildgrafik besteht, ist an dieser Stelle ein echter Bruch – mehr dazu unter Barrierefreie E-Mails & Newsletter.

Häufige Fragen

Ist die Shopware-Standard-Storefront barrierefrei?

Sie bringt eine brauchbare Grundlage mit – semantisches Markup, Bootstrap-Fokusringe, beschriftete Formularfelder. Ein Konformitätsversprechen für deinen Shop ist das nicht: Über die ausgelieferte Seite entscheiden dein Theme, deine Farben, deine Erlebniswelten und deine Plugins. Geprüft wird immer das Ergebnis.

Muss ich auf ein barrierefreies Theme wechseln?

Nur, wenn dein Theme grundlegend bricht – etwa mit entfernten Fokusringen, zu kontrastarmen Farben oder kaputter Überschriftenstruktur. In Shopware ist der übliche Weg ein Override statt eines Wechsels: Du erbst vom Standard-Theme und korrigierst gezielt die Blöcke, die Probleme machen.

Wer haftet, wenn ein Zahlungs-Plugin nicht barrierefrei ist?

Verpflichtet ist der Dienstleistungserbringer, also du als Shopbetreiber. Dass eine Komponente zugekauft ist, entlastet nicht – sie gehört zu deinem Angebot. Praktisch heißt das: Barrierefreiheit gehört in die Auswahlkriterien und in den Vertrag mit dem Anbieter.

Gilt das BFSG auch für meinen B2B-Shop?

Nur eingeschränkt. Das Gesetz schützt Verbrauchergeschäfte. Ein nachweislich rein geschäftlicher Shop fällt nicht darunter – die Betonung liegt auf nachweislich, eine AGB-Klausel reicht nicht. Sobald Verbraucher real bestellen können, zählt der Auftritt als B2C. Die Systematik dazu steht im BFSG-Schnelltest.

Wie halte ich den Zustand nach dem Launch?

Mit einem kurzen Regressionstest nach jedem größeren Update und nach jeder neuen Erlebniswelt: Kauf per Tastatur, Zoomtest, Formularfehler. Das dauert eine Viertelstunde. Wie sich der Zustand dokumentieren lässt, steht unter Barrierefreiheitserklärung erstellen.

Verwandte Themen

• Barrierefreiheit nach Plattform – die Übersicht über alle Systeme
• Barrierefreiheit in Onlineshops – die systemunabhängigen Shop-Anforderungen im Detail
• Barrierefreiheit mit Shopify – der Vergleichsfall mit weniger Kontrolle über den Checkout
• Komplexe Datentabellen – für Staffelpreise und Produktvergleiche
• BFSG-Checkliste für Websites – der vollständige Pflichtendurchgang

Quellen

• Barrierefreiheitsstärkungsgesetz (BFSG) (Gesetzestext – § 1 Anwendungsbereich, § 3 Ausnahmen)
• Shopware 6 Theme Guide (Shopware – Template-Overrides in der Twig-Storefront)
• Shopware UPGRADE-6.6 (Shopware – Feature-Flag ACCESSIBILITY_TWEAKS und die Änderungen an der Storefront)
• EN 301 549 (ETSI – der harmonisierte europäische Standard)
• Understanding SC 3.3.4 Error Prevention (W3C – Anforderungen an rechtsverbindliche Vorgänge)