Eigenes Shopware-Theme: Barrierefreiheit nicht verbauen

Seit Shopware 6.7 sind die Verbesserungen der Barrierefreiheit im Standard-Storefront kein Schalter mehr, sondern Grundeinstellung: Mit der Hauptversion 6.7.0 wurden alle diese Änderungen zum Standard (Shopware). Ein eigenes Shopware-Theme oder ein Plugin, das Twig-Blöcke überschreibt, kann diese Arbeit allerdings unbemerkt zurückdrehen. Wer einen Block ersetzt, statt ihn zu erweitern, liefert das Markup aus, das zum Zeitpunkt des Kopierens im Core stand. Dieser Beitrag zeigt, an welchen Stellen Shopware das Storefront-Markup für die Barrierefreiheit umgebaut hat, wie Theme- und Plugin-Overrides diese Änderungen überlagern und wie ein Override-Audit mit drei Prüfmarken je Schicht – Fokus, Listen-Markup, Tastatur – die Lücken findet. Die Prüfung und Umsetzung übernehmen wir im Rahmen unserer BFSG-Optimierung für Shops.

Was Shopware 6.7 im Storefront umgebaut hat

Shopware verpflichtet sich nach eigener Angabe, im Storefront die Richtlinien der WCAG 2.1 auf Stufe AA und die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) zu erfüllen (Shopware). Erste Verbesserungen kamen mit der Reihe 6.6, mit 6.7 weitere hinzu (Shopware). Ausgeliefert werden sie laufend in regulären Minor-Versionen, wie andere Verbesserungen auch (Shopware).

Entscheidend für eigene Themes: Barrierefreiheit kann einen Umbau der HTML- und Twig-Struktur oder des CSS erfordern, und ein solcher Umbau kann laut Shopware zu unbeabsichtigtem Verhalten in einer Erweiterung führen, die den betroffenen Bereich verändert (Shopware). Deshalb lagen solche Änderungen in der Reihe 6.6 hinter dem Feature-Flag ACCESSIBILITY_TWEAKS und waren standardmäßig ausgeschaltet. Mit der Hauptversion 6.7.0 wurden sie zum Standard (Shopware).

Mit der Hauptversion v6.7.0 werden alle Verbesserungen der Barrierefreiheit zum Standard.

Shopware-Entwicklerdokumentation, Accessibility in the Storefront (eigene Übersetzung)

Die konkreten Änderungen listen die Release Notes zu 6.7.0.0 auf und begründen sie mit dem European Accessibility Act (Shopware). Für Themes zählen vor allem diese Punkte, weil sie häufig überschriebene Templates betreffen:

Die Grundschriftgröße des Storefront wurde auf den Browserstandard von 1rem, also 16 px, angehoben (Shopware). In den Upgrade-Hinweisen steht dazu, dass $font-size-base von 0.875rem auf 1rem geändert wurde (Shopware). Ein Theme, das die alte Größe als Variable festschreibt, nimmt diese Verbesserung zurück. Anders als die technischen Brüche bei der Migration von Shopware-Plugins auf 6.7 erzeugt dieser Unterschied keinen Build-Fehler, sondern bleibt still im HTML.

Wie Theme und Plugins das Core-Markup überlagern

Ein Shopware-Theme legt in seiner Datei theme.json fest, in welcher Reihenfolge Templates zusammengesetzt werden. Im Abschnitt views stehen dafür typischerweise @Storefront, @Plugins und das eigene Theme. Beim Rendern dient das Storefront-Template als Basis (Shopware). Darauf werden die Erweiterungen der installierten Plugins angewendet (Shopware), danach die Änderungen der Themes in der angegebenen Reihenfolge.

Jede Storefront-Seite entsteht damit aus drei Schichten. Die unterste liefert Shopware selbst. Die mittlere stammt aus Plugins, etwa für Zahlungsarten oder Bewertungen, die oberste ist das Theme. Jede Schicht kann einen Twig-Block erweitern oder ersetzen. Ersetzt sie ihn, ist für diesen Block alles wirkungslos, was darunter liegt – auch jede Verbesserung, die Shopware später im Core nachliefert.

Technisch geschieht das über sw_extends und Block-Overrides. Die Entwicklerdokumentation zeigt das Prinzip am Logo: Ein eigenes Template erweitert die Originaldatei, übernimmt den Block mit demselben Namen und ersetzt dessen Inhalt (Shopware). Wer statt zu ersetzen nur etwas anhängen möchte, ruft im Block parent() auf. Dieser Unterschied entscheidet, ob ein Theme mit dem Core mitwächst; in unserer Shopware-Entwicklung ist er die erste Frage bei jedem Override. Ein Beispiel für die riskante Variante:

{% sw_extends '@Storefront/storefront/component/product/card/box-standard.html.twig' %}

{# Ersetzt den ganzen Block. Shopware 6.7 hat den Link um das Produktbild
   entfernt, diese Kopie aus einem älteren Theme bringt ihn zurück. #}
{% block component_product_box_image %}
    <div class="product-image-wrapper">
        <a href="{{ seoUrl('frontend.detail.page', { productId: id }) }}"
           class="product-image-link">
            {% sw_thumbnails 'product-image-thumbnails' with { media: cover } %}
        </a>
    </div>
{% endblock %}

In Shopware 6.7 trägt der Produktname in der Karte die Klasse stretched-link und macht damit die ganze Karte klickbar; der separate Link um das Bild wurde entfernt (Shopware). Ein Theme, das den Bildblock aus einer älteren Vorlage kopiert, setzt den zweiten Link wieder ein. Optisch ändert sich nichts, für Tastaturnutzer entstehen zwei Tabstopps je Produkt mit demselben Ziel. Die erweiternde Variante vermeidet das:

{% sw_extends '@Storefront/storefront/component/product/card/box-standard.html.twig' %}

{# Erweitert den Block: das Markup des Core bleibt erhalten und
   wächst bei jedem Update mit. #}
{% block component_product_box_image %}
    {{ parent() }}
    <span class="custom-badge">Neu im Sortiment</span>
{% endblock %}

Sechs Muster, mit denen Overrides Barrierefreiheit zurückdrehen

In Theme- und Plugin-Overrides wiederholen sich wenige Muster, meist ohne Absicht – ein Template wurde kopiert, als der Core es noch anders gebaut hat:

Keines dieser Muster lässt sich nachträglich mit einem eingeblendeten Skript zuverlässig überdecken. Warum Overlay-Widgets das BFSG-Risiko nicht lösen, haben wir gesondert beschrieben. Für Overrides gilt dasselbe: Die Korrektur gehört in das Template oder die SCSS-Datei, die den Fehler erzeugt.

Plugins: die Schicht zwischen Core und Theme

Theme-Overrides liegen im eigenen Projekt, Plugin-Overrides fallen seltener auf. Ein Plugin für eine Zahlungsart, einen Produktkonfigurator, Bewertungen oder Versandoptionen erweitert oft genau die Templates, die Shopware für die Barrierefreiheit umgebaut hat: Warenkorbpositionen, Checkout, Produktkarten, Kopfbereich.

Shopware erklärt das Problem selbst an einem Beispiel: Wird eine Liste aus div-Elementen auf ul und li umgestellt und eine Erweiterung fügt weiterhin ein div mit der Klasse list-item in den Block ein, entsteht vermutlich fehlerhaftes HTML (Shopware). Die Release Notes zu 6.7.0.0 nennen genau diese Umstellung für Bestellübersicht und Warenkorbpositionen (Shopware). Ein Plugin, das eigene Positionstypen im Warenkorb rendert, muss sein Wurzelelement deshalb auf li umstellen. Sonst steht im ausgelieferten HTML ein div in einer Liste.

Für Erweiterungen aus dem Shopware Store gilt: Entwickler können eine Erweiterung selbst als barrierefrei zertifizieren (Shopware). Eine Prüfung durch die Shopware-Qualitätssicherung kann für die Aufnahme in den Store verlangt werden (Shopware). Eine Freigabe im Store ersetzt daher nicht den Blick auf das Zusammenspiel im eigenen Shop.

Besonders sorgfältig gehört der Checkout geprüft. Die Verordnung zum BFSG verlangt für den elektronischen Geschäftsverkehr, dass Identifizierungs-, Authentifizierungs-, Sicherheits- und Zahlungsfunktionen, soweit sie im Rahmen der Dienstleistung bereitgestellt werden, wahrnehmbar, bedienbar, verständlich und robust gestaltet sind (BFSGV). Gerade diese Bereiche – Anmeldung, Adresseingabe, Zahlungsauswahl – werden in vielen Shops von Plugins erweitert.

Was das BFSG verlangt und warum das Theme dazugehört

Das Barrierefreiheitsstärkungsgesetz gilt nach § 1 Absatz 3 unter anderem für Dienstleistungen im elektronischen Geschäftsverkehr, die für Verbraucher nach dem 28. Juni 2025 erbracht werden (BFSG). Barrierefrei sind sie nach § 3 Absatz 1, wenn sie für Menschen mit Behinderungen in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe auffindbar, zugänglich und nutzbar sind (BFSG). Die konkreten Anforderungen regelt die Verordnung zum Gesetz.

Für die Frage nach Overrides ist § 14 Absatz 3 der wichtigste Satz: Der Dienstleistungserbringer gewährleistet, dass die Anforderungen dauerhaft erfüllt werden, wenn er die Dienstleistung anbietet oder erbringt (BFSG). Veränderungen bei der Art und Weise, wie die Dienstleistung erbracht wird, hat er dabei gebührend zu berücksichtigen (BFSG). Ein neues Theme, ein Plugin-Update oder ein Shopware-Update ist genau eine solche Veränderung. Barrierefreiheit ist damit kein Zustand, den man einmal herstellt, sondern einer, der jede Änderung am Shop überstehen muss.

Erfüllt ein Angebot harmonisierte Normen, deren Fundstellen im Amtsblatt der Europäischen Union veröffentlicht sind, wird nach § 4 vermutet, dass es die Anforderungen der Verordnung erfüllt, soweit die Normen sie abdecken (BFSG). Unabhängig davon sind die WCAG 2.1 auf Stufe AA, an denen sich auch Shopware ausrichtet, ein verbreiteter technischer Maßstab für die Prüfung.

• Bußgeld: Wer vorsätzlich oder fahrlässig entgegen § 14 Absatz 1 eine Dienstleistung anbietet oder erbringt, handelt ordnungswidrig; die Geldbuße kann bis zu 100.000 Euro betragen (BFSG).
• Kleinstunternehmen: Die Anforderungen an Dienstleistungen gelten nach § 3 Absatz 3 nicht für Kleinstunternehmen, die Dienstleistungen anbieten oder erbringen (BFSG).
• Inhalte Dritter: Ausgenommen sind nach § 1 Absatz 4 Inhalte von Dritten, die der Anbieter weder finanziert noch entwickelt noch kontrolliert (BFSG). Ein Plugin, das der Betreiber selbst auswählt, installiert und konfiguriert, unterliegt in der Regel seiner Kontrolle.

Der Gesetzgeber unterscheidet nicht danach, ob eine Barriere aus dem Core, einem Plugin oder dem Theme stammt. Die Pflichten liegen beim Dienstleistungserbringer, also beim Shopbetreiber. Zu den Pflichten gehören auch Informationen zur Barrierefreiheit; wie eine Barrierefreiheitserklärung mit Feedback-Mechanismus im Shop aussieht, beschreiben wir separat. Welche weiteren Pflichten und Stichtage 2027 auf Onlineshops zukommen, zeigt unser Fristenkalender für Onlineshops.

Was Messdaten über typische Fehler sagen

Wie verbreitet die Fehler sind, die in Templates entstehen, zeigt die WebAIM Million 2026. WebAIM hat dafür die Startseiten der eine Million meistbesuchten Websites automatisiert geprüft (WebAIM); die Ergebnisse stammen aus dem Februar 2026 (WebAIM). Auf 95,9 Prozent dieser Startseiten fanden sich erkannte WCAG-2-Fehler (WebAIM). Im Schnitt waren es 56,1 erkannte Fehler je Seite (WebAIM). Startseiten der Kategorie Shopping lagen mit durchschnittlich 71,0 Fehlern 26,6 Prozent über diesem Mittelwert (WebAIM).

Diese sechs Fehlerarten machen zusammen 96 Prozent aller erkannten Fehler aus (WebAIM). Viele davon entstehen im Markup und in den Farben, also dort, wo Theme und Plugins eingreifen. Zwei weitere Befunde passen ins Bild: Startseiten mit ARIA-Attributen hatten im Schnitt 59,1 erkannte Fehler, Seiten ohne ARIA 42 (WebAIM). WebAIM betont, dass ARIA diese Fehler nicht zwingend verursacht hat, weil die Seiten auch komplexer waren (WebAIM). Und jeder zehnte Sprunglink war defekt, weil er unzugänglich versteckt war oder sein Ziel auf der Seite fehlte (WebAIM).

Zwei Einschränkungen gehören zu diesen Zahlen. Sie beziehen sich auf Startseiten, nicht auf Kategorie-, Produkt- oder Checkout-Seiten, in denen Shops viele ihrer Overrides tragen. Und sie erfassen nur automatisch erkennbare Fehler: Eine Seite ohne erkannte Fehler ist damit noch nicht barrierefrei oder konform (WebAIM). Welche Erfolgskriterien mit WCAG 2.2 dazugekommen sind, haben wir im Beitrag zu den neuen WCAG-2.2-Kriterien für Onlineshops zusammengefasst.

Farben und Schrift: was die Theme-Konfiguration beeinflusst

Nicht jede Barriere entsteht im Twig. Ein Theme legt über die Datei theme.json und die Konfiguration in der Administration auch Farben fest, etwa die Primärfarbe über das Feld sw-color-brand-primary (Shopware). Für Variablen von Shopware oder Bootstrap ist die Datei overrides.scss vorgesehen, die vor den Standardstilen eingebunden wird (Shopware). Das vermeidet Kopien von Templates, verlagert die Verantwortung aber auf die eingetragenen Werte.

Text braucht nach WCAG 2.1 ein Kontrastverhältnis von mindestens 4,5:1 (W3C), großer Text mindestens 3:1 (W3C). Eine Markenfarbe, die als Hintergrund für Buttons gut funktioniert, kann als Schriftfarbe für Links oder Preise auf hellem Grund deutlich darunter liegen. Zu geringer Kontrast ist in der WebAIM Million die häufigste erkannte Fehlerart, gefunden auf 83,9 Prozent der Startseiten (WebAIM). Wir prüfen deshalb jede Farbe der Theme-Konfiguration in jeder Rolle: als Text, Hintergrund, Rahmen und Fokusfarbe.

Drei Prüfmarken je Schicht: Fokus, Listen, Tastatur

Ein Override-Audit braucht einen festen Maßstab. Wir prüfen jede Schicht – Core, Plugins, Theme – und das ausgelieferte Ergebnis gegen drei Prüfmarken, die sich direkt auf Erfolgskriterien der WCAG 2.1 zurückführen lassen:

Das Kriterium 2.4.7 verlangt, dass jede per Tastatur bedienbare Oberfläche einen Modus hat, in dem der Tastaturfokus sichtbar ist (W3C). Kriterium 1.3.1 verlangt, dass Informationen, Struktur und Beziehungen, die über die Darstellung vermittelt werden, programmatisch ermittelbar oder als Text verfügbar sind (W3C) – eine Liste muss also im Code eine Liste sein, nicht nur so aussehen. Nach Kriterium 2.1.1 muss die gesamte Funktionalität über eine Tastaturschnittstelle bedienbar sein (W3C).

Als vierten Punkt nehmen wir Name und Rolle hinzu, weil die Änderung an sw_icon genau dort ansetzt: Nach Kriterium 4.1.2 müssen Name und Rolle aller Bedienelemente programmatisch ermittelbar sein (W3C). Ein Button, der nur ein ausgeblendetes Icon enthält, hat keinen Namen. Die Grafik am Anfang des Beitrags zeigt das Prinzip an einem Beispiel: Der Core erfüllt dort alle Prüfmarken, ein Plugin verliert das Listen-Markup, das Theme den Fokus – und das ausgelieferte HTML erbt beide Verluste.

Das Override-Audit Schritt für Schritt

Das allgemeine Vorgehen bei einer Prüfung nach BFSG beschreibt unser Beitrag zum BFSG-Audit für Onlineshops. Für Shopware kommt ein Schritt davor hinzu, der in allgemeinen Prüfungen oft fehlt: die Bestandsaufnahme der Overrides.

1. Inventar anlegen: alle Template-Dateien unter Resources/views in Theme und Plugins erfassen, mit Pfad, erweitertem Original und überschriebenen Blöcken.
2. Ersetzen von Erweitern trennen: Jeder Block ohne parent() ersetzt das Original vollständig. Diese Blöcke sind die erste Prüfliste.
3. Gegen den Core abgleichen: Für jeden ersetzten Block die aktuelle Fassung im Storefront danebenlegen. In 6.6-Templates markieren Hinweise wie @deprecated tag:v6.7.0 die Stellen, die Shopware für 6.7 umgebaut hat.
4. SCSS mitprüfen: Variablen-Overrides in overrides.scss und Regeln in base.scss auf outline, Schriftgrößen und Farbwerte durchsehen.
5. Im Browser messen: die Prüfmarken auf Startseite, Kategorie, Produkt, Warenkorb, Checkout und Kundenkonto prüfen – mit Tastatur allein, mit einem Screenreader und ergänzend mit automatisierten Prüfungen.
6. Befunde der Schicht zuordnen: Jeder Fehler bekommt die Schicht, aus der er stammt. Nur so lässt sich entscheiden, ob Theme, Plugin oder ein Update die Korrektur trägt.

Die Suche liefert nur Kandidaten: Auch ein Block mit parent() kann Markup um das Original legen, das die Semantik bricht. Gemessen wird deshalb am Ergebnis im Browser. Für diese Prüfung eignet sich eine Staging-Umgebung mit realistischen, aber anonymisierten Daten; wie sie sich aufbauen lässt, steht im Beitrag zu Shopware-Staging mit Testdaten ohne Kundendaten.

Shops auf 6.6: mit ACCESSIBILITY_TWEAKS vorab testen

Wer noch auf Shopware 6.6 arbeitet, kann die Änderungen vorab testen. Das Feature-Flag ACCESSIBILITY_TWEAKS wird in der .env des Projekts gesetzt; dann sind alle verfügbaren Verbesserungen der Barrierefreiheit aktiv, und es zeigt sich, ob Projekt oder Erweiterungen betroffen sind (Shopware). Nach dem Einschalten ist das Theme neu zu kompilieren, damit auch Stiländerungen wie die angepassten Schriftgrößen greifen (Shopware). Auf einer Staging-Umgebung sieht das so aus:

Schon in der Reihe 6.6 kamen einzelne brechende Änderungen hinter diesem Flag, etwa die Umstellung der Paginierung auf Links mit Version 6.6.6.0 (Shopware). Wer das Flag erst beim Wechsel auf 6.7 bemerkt, bekommt alle Änderungen auf einmal – zusammen mit den übrigen Brüchen der Hauptversion. Wie sich der Zeitplan bis zur nächsten Hauptversion einordnet, beschreiben die Beiträge zur Vorbereitung auf Shopware 6.8 und zum Ende der Sicherheitsupdates für Shopware 6.5.

Overrides so schreiben, dass Updates sie nicht aushebeln

Ein gutes Override ist klein, begründet und überprüfbar:

• Kleinsten Block wählen: Je tiefer der überschriebene Block liegt, desto weniger fremdes Markup steht in der eigenen Datei.
• Mit parent() erweitern: Wer anhängt statt ersetzt, bekommt Verbesserungen des Core bei jedem Update mit.
• Konfiguration vor Kopie: Farben, Schriften und Abstände gehören in die Theme-Konfiguration und SCSS-Variablen, nicht in kopierte Templates.
• Fokus gestalten, nicht entfernen: Passt der Standard-Fokus nicht zum Design, einen eigenen, gut sichtbaren Fokusstil definieren.
• Overrides dokumentieren: je Datei festhalten, warum der Block überschrieben wird und gegen welche Shopware-Version er zuletzt abgeglichen wurde.
• Bei jedem Minor-Update abgleichen: Weil Shopware Verbesserungen der Barrierefreiheit laufend in Minor-Versionen ausliefert (Shopware), gehört der Abgleich der Overrides in jede Wartungsrunde.

Für neue Bausteine bietet Shopware seit Version 6.7.11.0 ein Komponentensystem, mit dem sich atomare Template-Komponenten wiederverwendbar im Storefront zusammensetzen lassen (Shopware). Was das für die Storefront-Entwicklung bedeutet, steht im Beitrag zu Vite-Devserver und Twig-UX in Shopware 6.7.11. Den regelmäßigen Abgleich der Overrides übernehmen wir in der Shopware-Wartung, zusammen mit Core- und Plugin-Updates in einer Staging-Umgebung.

Barrierefreiheit im Theme dauerhaft absichern

Shopware hat mit 6.7 die Grundlage verbessert; ob sie bei Kundinnen und Kunden ankommt, entscheiden Theme und Plugins. Wir unterstützen in drei Schritten:

Einen ersten Überblick gibt unser Shop-Check, der neben Ladezeit und SEO-Grundlagen auch die Barrierefreiheit betrachtet. Für die vollständige Prüfung und Umsetzung steht unsere BFSG-Optimierung bereit.