BFSG & Shopware 6: Was Online-Shops bei der Barrierefreiheit jetzt umsetzen müssen

1. Was das BFSG verlangt — und seit wann

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt den European Accessibility Act in deutsches Recht um und gilt verbindlich seit dem 28. Juni 2025. Eine Übergangsfrist gibt es nicht mehr — die Marktüberwachungsbehörden der Länder können seitdem prüfen.

Der technische Maßstab ist nicht das Gesetz selbst, sondern die harmonisierte europäische Norm EN 301 549, die wiederum auf den WCAG 2.1 auf Konformitätsstufe AA verweist. Wer also wissen will, ob sein Shop „barrierefrei genug" ist, prüft gegen WCAG 2.1 AA — das ist die Messlatte, die Gerichte und Behörden anlegen.

Hinweis: Ich bin Entwickler, kein Anwalt. Dieser Artikel ordnet die technische Umsetzung ein und ersetzt keine Rechtsberatung — für die konkrete rechtliche Bewertung deines Shops solltest du eine auf E-Commerce-Recht spezialisierte Kanzlei hinzuziehen.

2. Wer betroffen ist — und die Kleinstunternehmen-Ausnahme

Betroffen sind im Kern Shops, die sich an Verbraucher richten (B2C). Der elektronische Geschäftsverkehr — also ein Webshop mit Bestellfunktion — ist explizit eine vom BFSG erfasste Dienstleistung.

Es gibt eine Ausnahme für Kleinstunternehmen, die Dienstleistungen erbringen: weniger als 10 Beschäftigte und höchstens 2 Mio. Euro Jahresumsatz bzw. Bilanzsumme. Wer darunter liegt, ist als Dienstleister vom BFSG ausgenommen. Diese Schwelle solltest du aber sauber rechtlich abklopfen, statt dich blind darauf zu verlassen — und im Zweifel trotzdem auf Barrierefreiheit setzen.

Eine Nuance, die im B2B-Umfeld oft untergeht: Richtet sich ein Shop ausschließlich an gewerbliche Kunden und ist Verbrauchern gar nicht erst zugänglich, kann er außerhalb des Anwendungsbereichs liegen. Sobald aber auch nur potenziell Verbraucher kaufen können, greift die Pflicht. Bei gemischten B2B/B2C-Shops ist die sichere Annahme: Das BFSG gilt.

3. Was bei Verstößen droht

Das BFSG ist kein Papiertiger. Die Marktüberwachungsbehörde kann die Einhaltung prüfen, Unterlagen anfordern und Mängel beanstanden. Bei Verstößen sind Bußgelder von bis zu 100.000 Euro möglich, und im Extremfall kann die Untersagung der Dienstleistung — also die Abschaltung des Shops — angeordnet werden.

Praktisch relevanter als die Behörde ist für viele Händler aber das Abmahnrisiko durch Wettbewerber und Verbände: Eine nicht barrierefreie Bestellstrecke ist ein angreifbarer Wettbewerbsverstoß. Hinzu kommt eine Dokumentationspflicht — du musst belegen können, dass und wie du die Anforderungen erfüllst. Eine Barrierefreiheitserklärung auf der Website gehört dazu.

4. Standard-Storefront: Was Shopware ab 6.7 schon mitbringt

Die gute Nachricht für alle mit dem Standard-Theme: Shopware hat erheblich vorgearbeitet. Mit Version 6.6 kamen umfangreiche Anpassungen am Standard-Theme — Tastaturbedienbarkeit für Filter und Pagination, Screenreader-Unterstützung mit Alt-Texten für interaktive Symbole und Bewertungen, optimierte Farbkontraste in der Standard-Palette.

Der Haken in 6.6: Diese Verbesserungen sind nicht automatisch aktiv. Sie hängen am Feature-Flag ACCESSIBILITY_TWEAKS, das du projektseitig in der .env setzen musst — gefolgt von einer Theme-Recompilation. Weil das Flag teils breaking Template-Änderungen mitbringt, lässt es sich bewusst nicht über die Administration aktivieren. Ab Shopware 6.7 ist es standardmäßig an, du musst nichts mehr manuell setzen.

Heißt konkret: Bist du auf 6.7, ist das Fundament da. Bist du noch auf 6.6, ist die Aktivierung des Feature-Flags der erste Schritt — mit anschließendem Test, weil das Flag auch eigene Themes und Extensions beeinflusst.

5. Wo der Standard nicht reicht: deine Custom-Bereiche

Das aktivierte Flag macht das Standard-Theme konform — nicht deinen Shop. Genau an den Stellen, an denen sich Shops unterscheiden, liegt die eigentliche Arbeit:

• Eigene Templates & PluginsJedes überschriebene Twig-Template, jedes Plugin mit eigenem Storefront-Output fällt nicht automatisch unter die Shopware-Tweaks. Custom-Buttons brauchen erreichbare Beschriftungen, eigene Formularfelder ein verknüpftes label, interaktive Elemente einen sichtbaren Fokus.
• Der CheckoutDie kritischste Strecke überhaupt. Fehlermeldungen müssen programmatisch mit dem Feld verknüpft und für Screenreader angekündigt werden, jeder Schritt per Tastatur bedienbar sein, der Fokus nach einem Validierungsfehler korrekt gesetzt werden. Ein Checkout, den man nicht ohne Maus abschließen kann, ist der teuerste Mangel.
• CMS-Inhalte & Shopping ExperiencesRedaktionell gepflegte Inhalte sind die häufigste Fehlerquelle: Bilder ohne Alt-Text, Kontraste unter dem AA-Schwellwert, Überschriften, die optisch statt semantisch ausgezeichnet sind. Hier hilft kein Feature-Flag, sondern nur Redaktions-Disziplin.
• PDFs & PflichtangabenEnergie-Labels, Datenblätter und sonstige Pflichtinformationen dürfen nicht nur als Bild oder nicht-barrierefreies PDF vorliegen, sondern müssen als maschinenlesbarer Text zugänglich sein.

6. Headless-Shops: Hier liegt der volle Aufwand bei dir

Wer ein entkoppeltes Frontend mit Next.js oder einem anderen Framework betreibt, kann sich auf Shopwares Theme-Tweaks gar nicht erst berufen — das Standard-Theme ist nicht im Einsatz. Die komplette WCAG-2.1-AA-Konformität ist Aufgabe des selbst gebauten Frontends.

Das ist kein Grund zur Panik, aber eine klare Konsequenz für die Architektur. Wer ein React-Frontend von Grund auf baut, hat alle Hebel selbst in der Hand — semantisches HTML statt div-Wüsten, korrektes Fokus-Management bei client-seitiger Navigation, ARIA nur dort, wo natives HTML nicht reicht, und durchdachte Live-Regions für dynamische Updates wie das Hinzufügen zum Warenkorb. Der Punkt ist: Barrierefreiheit muss von Anfang an Teil des Komponenten-Designs sein. Sie nachträglich über eine fertige UI zu legen, ist um ein Vielfaches teurer.

Genau das ist im Headless-Setup oft der unterschätzte Posten: Was im Standard-Storefront zur Konfigurationsaufgabe wird, ist im Custom-Frontend echte Entwicklungsarbeit — die früh in den Aufwand eingeplant gehört.

7. Pragmatischer Fahrplan

Wer jetzt erst anfängt, sollte nicht versuchen, alles auf einmal perfekt zu machen, sondern nach Risiko priorisieren:

• 1. BestandsaufnahmeAutomatisierter Scan (z.B. axe oder Lighthouse) plus manueller Tastatur- und Screenreader-Test der Kern-Strecke: Startseite → Produkt → Warenkorb → Checkout. Das zeigt die gröbsten Verstöße in einer Stunde.
• 2. Version klärenAuf 6.7 ist das Standard-Theme weitgehend konform — Upgrade von 6.6 lohnt sich hier doppelt. Auf 6.6 zunächst das ACCESSIBILITY_TWEAKS-Flag aktivieren und testen.
• 3. Checkout zuerstDie Bestellstrecke barrierefrei machen, bevor du dich um Randseiten kümmerst. Hier sitzt das größte rechtliche und wirtschaftliche Risiko.
• 4. DokumentierenBarrierefreiheitserklärung erstellen und den Stand festhalten. Auch ein „in Arbeit, mit Maßnahmenplan" ist besser als gar nichts.

Barrierefreiheit ist lästig, solange man sie als reine Pflicht sieht. Praktisch bedeutet ein sauber bedienbarer Checkout aber auch: weniger Abbrüche, bessere SEO, eine Zielgruppe, die sonst woanders kauft. Die Pflicht und der Nutzen zeigen hier ausnahmsweise in dieselbe Richtung.