BFSG-Checkliste für Shopware 6: So wird dein Online-Shop barrierefrei

Was das BFSG für Online-Shops bedeutet

Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt in Deutschland seit dem 28. Juni 2025. Es setzt die europäische Richtlinie European Accessibility Act (EAA) in nationales Recht um und verpflichtet Anbieter digitaler Produkte und Dienstleistungen, darunter B2C-Online-Shops, zur Einhaltung definierter Barrierefreiheitsstandards. Technischer Referenzrahmen ist die WCAG 2.1, Konformitätsstufe AA, ergänzt durch die harmonisierte europäische Norm EN 301 549.

Anwendungspraktisch heißt das: Ein Shop muss so gestaltet sein, dass Menschen mit Behinderungen ihn wahrnehmen, bedienen, verstehen und robust nutzen können. Das sind die vier POUR-Prinzipien der WCAG. Betroffen sind nicht nur blinde Nutzer mit Screen-Readern, sondern auch Personen mit motorischen Einschränkungen, kognitiven Beeinträchtigungen oder Sehschwächen.

Die Übergangsfrist ist abgelaufen. Wer heute nicht konform ist, verstößt gegen geltendes Recht. Erste Abmahnungen durch Wettbewerber und Verbände sind dokumentiert.

Wen das Gesetz betrifft

Das BFSG gilt für alle B2C-Online-Shops, die Waren oder Dienstleistungen an Endverbraucher in Deutschland anbieten. Erfasst sind auch Shops mit Sitz im EU-Ausland, sofern sie den deutschen Markt bedienen.

Ausnahme: Kleinstunternehmen mit weniger als 10 Beschäftigten und einem Jahresumsatz oder einer Jahresbilanzsumme von unter 2 Millionen Euro sind ausgenommen. Beide Kriterien müssen gleichzeitig erfüllt sein. Sobald eines überschritten wird, greift die Pflicht.

Zur Verantwortung: Liegt der Shop bei einer Agentur, ist Adressat der Pflicht trotzdem der Dienstleistungserbringer, also der Shop-Betreiber selbst. Agenturen treffen jedoch vertragliche Informations- und Lieferpflichten gegenüber ihren Kunden.

Die 10-Punkte-Checkliste für Shopware 6

Die folgende Checkliste deckt die zehn Bereiche ab, die in Audits bei Shopware-6-Shops am häufigsten nicht konform sind.

1. Kontrastverhältnisse prüfen und Theme anpassen

Die WCAG 2.1 AA fordert ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text (ab 18pt oder 14pt fett). Viele Shopware-Themes, vor allem Custom Themes, verwenden helle Akzentfarben, die diese Schwellen nicht erreichen.

In der base.scss oder den Theme-Variablen:

// ❌ Vorher: Kontrast 2.8:1
$sw-color-brand-primary: #7eb8da;

// ✅ Nachher: Kontrast 5.2:1
$sw-color-brand-primary: #2a7ab5;

// Textfarben sicherstellen
$sw-text-color: #1a1a1a; // Kontrast 15.4:1 auf Weiß
$sw-text-color-secondary: #4a4a4a; // Kontrast 9.7:1

Validiere jede Farbkombination mit dem WebAIM Contrast Checker. Geprüft werden müssen auch Placeholder-Texte, Badges und Preisangaben.

2. Alt-Texte für alle Produktbilder

Jedes informative Bild benötigt einen beschreibenden Alt-Text. In Shopware 6 werden Produktbilder über die Media-Verwaltung eingebunden. Im Admin unter Kataloge → Produkte → Medien erhält jedes Bild einen aussagekräftigen Alt-Text.

Ein Fallback im Twig-Template hält das System robust, falls ein Pflegevorgang vergessen wird:

{% block component_product_image %}
  <img
    src="{{ media.url }}"
    alt="{{ media.alt ?: product.translated.name ~ ' – Produktbild' }}"
    loading="lazy"
    width="{{ media.metaData.width }}"
    height="{{ media.metaData.height }}"
  >
{% endblock %}

Dekorative Bilder (Hintergründe, Trennlinien) erhalten ein leeres alt="" und idealerweise role="presentation".

3. Tastaturnavigation im gesamten Checkout

Der vollständige Kaufprozess vom Warenkorb über die Adresseingabe bis zur Zahlungsbestätigung muss per Tastatur bedienbar sein. Geprüft wird mit Tab, Shift+Tab, Enter und Escape.

Häufige Defekte in Shopware 6:

• Custom Dropdown-Selects für die Länderwahl ohne Keyboard-Support
• Modale Dialoge (z. B. Adressauswahl) ohne Focus-Trap
• Zahlungsart-Auswahl mit Custom-Radio-Buttons ohne role="radio"

Ein minimaler Focus-Trap für Modale:

// focus-trap.plugin.js
import Plugin from 'src/plugin-system/plugin.class';

export default class FocusTrapPlugin extends Plugin {
  init() {
    this._focusableEls = this.el.querySelectorAll(
      'a[href], button:not([disabled]), input, select, textarea, [tabindex]:not([tabindex="-1"])'
    );
    this._firstEl = this._focusableEls[0];
    this._lastEl = this._focusableEls[this._focusableEls.length - 1];
    this.el.addEventListener('keydown', this._handleKeydown.bind(this));
    this._firstEl?.focus();
  }

  _handleKeydown(e) {
    if (e.key !== 'Tab') return;
    if (e.shiftKey && document.activeElement === this._firstEl) {
      e.preventDefault();
      this._lastEl.focus();
    } else if (!e.shiftKey && document.activeElement === this._lastEl) {
      e.preventDefault();
      this._firstEl.focus();
    }
  }
}

4. Formulare mit klaren Fehlermeldungen

Formularfelder benötigen sichtbare <label>-Elemente, nicht nur Placeholder. Fehlermeldungen müssen programmatisch mit dem Feld verknüpft sein.

{% block component_address_form_field_name %}
  <div class="form-group{% if formViolations.firstName %} has-error{% endif %}">
    <label for="addressFirstName" class="form-label">
      {{ 'address.firstNameLabel'|trans }}*
    </label>
    <input
      type="text"
      id="addressFirstName"
      name="firstName"
      class="form-control"
      required
      aria-required="true"
      aria-describedby="{% if formViolations.firstName %}firstName-error{% endif %}"
      aria-invalid="{{ formViolations.firstName ? 'true' : 'false' }}"
    >
    {% if formViolations.firstName %}
      <div id="firstName-error" class="invalid-feedback" role="alert">
        {{ formViolations.firstName.message }}
      </div>
    {% endif %}
  </div>
{% endblock %}

Zwei Attribute sind entscheidend: aria-describedby verknüpft das Feld mit der Fehlermeldung, role="alert" veranlasst Screen-Reader, die Meldung unmittelbar vorzulesen.

5. Skip-Navigation und Landmark-Rollen

Nutzer mit Tastatur oder Screen-Reader müssen repetitive Navigationsbereiche überspringen können. In der base.html.twig ganz am Anfang:

{% block base_body %}
  <a class="skip-link sr-only sr-only-focusable" href="#main-content">
    Zum Hauptinhalt springen
  </a>
  <a class="skip-link sr-only sr-only-focusable" href="#footer-navigation">
    Zur Footer-Navigation springen
  </a>
  {{ parent() }}
{% endblock %}

Zusätzlich sind die semantischen Landmark-Rollen korrekt zu setzen:

<header role="banner">...</header>
<nav role="navigation" aria-label="Hauptnavigation">...</nav>
<main id="main-content" role="main">...</main>
<aside role="complementary">...</aside>
<footer id="footer-navigation" role="contentinfo">...</footer>

6. Barrierefreier Cookie-Banner

Cookie-Banner gehören zu den häufigsten Fundstellen in Audits. Anforderungen:

• Der Banner erhält direkt nach dem Laden den Fokus.
• Alle Buttons sind per Tastatur erreichbar.
• Die Auswahl ist mit Screen-Readern verständlich.
• Der „Alle akzeptieren"-Button darf nicht visuell bevorzugt sein (Dark-Pattern-Verbot).

Wer Plugins wie Consentmanager oder Cookiebot einsetzt, prüft die Barrierefreiheit eigenständig. Nicht alle Anbieter erfüllen die Anforderungen vollständig. Testverfahren: Tab durch den gesamten Banner, zusätzlich Screen-Reader-Probe mit NVDA oder VoiceOver.

7. Responsive Schriftgrößen ohne festes px

Nutzer müssen Text auf 200 % vergrößern können, ohne dass Inhalte abgeschnitten werden oder sich überlappen (WCAG 1.4.4). Statt px werden rem oder em verwendet:

// ❌ Nicht barrierefrei
.product-title { font-size: 14px; }

// ✅ Barrierefrei
.product-title { font-size: 0.875rem; }

// Basis sicherstellen
html { font-size: 100%; } // = 16px Standard

Der Test erfolgt über die Browser-Zoom-Funktion auf 200 %. Akzeptanzkriterien: Alle Inhalte bleiben lesbar, kein horizontales Scrollen entsteht.

8. Video-Untertitel und Audiodeskription

Produktvideos und Erlebniswelten-Videos benötigen Untertitel (Captions) für gehörlose Nutzer. Für blinde Nutzer ist zusätzlich eine Audiodeskription vorgesehen.

<video controls>
  <source src="/media/produkt-demo.mp4" type="video/mp4">
  <track kind="captions" src="/media/produkt-demo-de.vtt" srclang="de" label="Deutsch" default>
  <track kind="descriptions" src="/media/produkt-demo-ad.vtt" srclang="de" label="Audiodeskription">
</video>

9. Barrierefreiheitserklärung im Footer

Das BFSG verlangt eine Erklärung zur Barrierefreiheit, die leicht auffindbar sein muss. Üblicherweise wird sie als eigene CMS-Seite angelegt und im Footer verlinkt. Pflichtbestandteile der Erklärung:

• Stand der Konformität (vollständig, teilweise oder nicht konform)
• Bekannte Einschränkungen mit Begründung
• Kontaktmöglichkeit für Barrieren-Meldungen (Feedback-Mechanismus)
• Verweis auf die zuständige Durchsetzungsstelle
• Datum der letzten Prüfung

10. Automatisierte und manuelle Prüfung kombinieren

Automatisierte Tools decken nach Branchenangaben rund 30 bis 40 Prozent aller Barrieren ab. Eine vollständige Prüfung kombiniert beide Verfahren.

Automatisiert:

• axe DevTools (Browser-Extension): findet WCAG-Verstöße im DOM
• WAVE (WebAIM): visuelle Darstellung der Probleme
• Lighthouse Accessibility Audit: in den Chrome DevTools integriert

Manuell:

• Vollständiger Checkout ausschließlich per Tastatur
• Screen-Reader-Test mit NVDA (Windows) oder VoiceOver (macOS)
• Zoom auf 200 %
• Simulation verschiedener Formen der Farbenblindheit

Shopware-6-spezifische Fallstricke

Shopware 6 bringt als modernes Framework eine solide Basis mit. Drei Bereiche fallen in Audits dennoch regelmäßig auf.

Custom Themes

Das Standard-Theme (Storefront) ist solide aufgestellt. Custom Themes brechen die Barrierefreiheit häufig. Typische Defekte: fehlende ARIA-Labels in Custom-Headern, Mega-Menüs ohne Keyboard-Support, Slider ohne Pause-Button.

Erlebniswelten (Shopping Experiences)

Die CMS-Blöcke der Erlebniswelten sind ein Risikofeld. Kritisch sind:

• Bild-Slider: häufig ohne Alt-Texte, ohne Pause-Funktion, ohne Tastatursteuerung.
• Bild-Text-Kombinationen: Text als Overlay auf Bildern ohne ausreichenden Kontrast.
• Custom CMS-Blöcke: häufig ohne semantische Struktur.

Jeder CMS-Block ist einzeln zu prüfen. Wo nötig, werden barrierefreie Alternativen erstellt:

{% block cms_element_image_slider %}
  <div
    class="cms-element-image-slider"
    role="region"
    aria-label="Bildergalerie: {{ element.config.title.value }}"
    aria-roledescription="Karussell"
  >
    <button
      class="slider-pause"
      aria-label="Automatische Wiedergabe pausieren"
    >
      ⏸
    </button>
    {{ parent() }}
  </div>
{% endblock %}

Listing-Filter

Die Produktlisting-Filter (Preis-Slider, Farb-Auswahl, Eigenschafts-Filter) sind häufig nicht barrierefrei. Der Preis-Range-Slider ist per Tastatur nur eingeschränkt bedienbar. Lösung: zusätzlich numerische Eingabefelder anbieten.

{% block component_filter_range %}
  <div role="group" aria-label="Preisfilter">
    <label for="price-min">Mindestpreis (€)</label>
    <input type="number" id="price-min" min="0" step="1" aria-valuemin="0">
    <label for="price-max">Höchstpreis (€)</label>
    <input type="number" id="price-max" min="0" step="1">
  </div>
{% endblock %}

Tools für den BFSG-Audit

Kostenlose Tools

Kostenpflichtige Tools

Konsequenzen bei Verstößen

Die Sanktionen sind in zwei Kategorien gegliedert.

Bußgelder

Die zuständigen Marktüberwachungsbehörden der Bundesländer können Bußgelder bis zu 100.000 Euro verhängen. Bei fortgesetzten Verstößen sind Verkaufsverbote für die betroffenen Produkte oder Dienstleistungen vorgesehen.

Abmahnungen

In der Praxis relevanter: Das BFSG eröffnet Wettbewerbern und Verbraucherschutzverbänden die Möglichkeit, Verstöße wettbewerbsrechtlich abzumahnen. Die Kosten einer Abmahnung liegen typischerweise zwischen 1.500 und 5.000 Euro pro Verstoß. Bei systematischen Mängeln summiert sich der Betrag.

Spezialisierte Kanzleien für BFSG-Abmahnungen sind bereits aktiv. Die technische Nachweisbarkeit eines Verstoßes ist im Vergleich zu früheren Abmahnwellen (etwa der DSGVO 2018) höher, weil sich Barrieren mit Standard-Tools dokumentieren lassen.

Reputationsrisiko

Öffentlich bekannte Barrierefreiheits-Mängel wirken sich auf das Markenbild aus. Das Gewicht dieses Faktors hängt von Branche und Zielgruppe ab und lässt sich nicht pauschal quantifizieren.

Barrierefreiheit und SEO

Barrierefreiheit und SEO überlappen technisch. Mehrere WCAG-Anforderungen wirken direkt auf das Google-Ranking.

Semantisches HTML

Korrekte Überschriftenhierarchien (h1 bis h6), semantische Landmarks und strukturierte Inhalte helfen Screen-Readern und dem Googlebot gleichermaßen beim Verständnis der Seite.

Core Web Vitals

Bilder mit width- und height-Attributen reduzieren Cumulative Layout Shift (CLS). Schlanke Seiten ohne unnötige Overlay-Skripte verbessern Largest Contentful Paint (LCP) und Interaction to Next Paint (INP).

Alt-Texte und Bildersuche

Beschreibende Alt-Texte verbessern die Sichtbarkeit in der Google-Bildersuche, einem für E-Commerce relevanten Traffic-Kanal.

Mobile Usability

Responsive Schriftgrößen, ausreichend große Touch-Targets (mindestens 44×44px) und eine logische Tab-Reihenfolge wirken sich positiv auf die mobile Nutzererfahrung aus, einem direkten Ranking-Faktor.

Fazit

Das BFSG ist seit Juni 2025 in Kraft und verbindlich. Barrierefreiheit ist damit Compliance-Pflicht und gleichzeitig eine Investition mit Nebenwirkungen in Richtung Usability und SEO.

Für Shopware 6 lässt sich die Umsetzung systematisch angehen. Voraussetzungen sind: Audit-Befund, priorisierte Maßnahmenliste, definierte Verantwortlichkeiten, Re-Test nach Umsetzung. Die hier gezeigte 10-Punkte-Liste ist der pragmatische Einstieg in genau diese Reihenfolge.

Audit für deinen Shopware-6-Shop

Wenn du wissen willst, wie konform dein Shop heute ist, machen wir einen kostenlosen Erst-Audit: automatisierte Prüfung, manuelle Stichprobe an Checkout und Erlebniswelten, schriftlicher Befund mit priorisierten Maßnahmen.

Mehr zu unseren E-Commerce-Leistungen

Unsere Shopware-Expertise im Detail

Du erreichst uns über das Kontaktformular oder direkt per E-Mail.