Zum Inhalt springen
Logo von nextlevels
Projekt anfragen

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

E-Commerce & Shopware

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.

Bei der Norm lohnt ein genauer Blick, weil hier viel Halbwissen kursiert. Die im EU-Amtsblatt zitierte Version 3.2.1 wurde für die Web-Richtlinie (EU) 2016/2102 erstellt, also für öffentliche Stellen — nicht für den European Accessibility Act. Die erste Fassung, die unter dem EAA-Mandat entsteht, ist V4.1: Sie richtet die Web-Kapitel an WCAG 2.2 aus und bringt mit Annex ZB erstmals eine Zuordnung zu den EAA-Anforderungen.

Der Final draft V4.1.0 liegt seit Juni 2026 vor und steckt in der Abstimmung bei ETSI; ein Datum für die Amtsblatt-Zitierung ist nicht zugesagt.

Praktische Folge: Eine formale Konformitätsvermutung über EN 301 549 gibt es für das BFSG heute noch nicht. Die Norm ist trotzdem der Maßstab, an dem geprüft wird. Verbindlicher Mindeststandard bleibt WCAG 2.1 AA. Wer jetzt umsetzt, nimmt sinnvollerweise gleich WCAG 2.2 AA mit: WCAG 2.2 bringt neun neue Erfolgskriterien, davon sechs auf den relevanten Stufen A und AA; dafür entfällt das alte Kriterium 4.1.1 (Parsing). Dann muss beim Normwechsel niemand nachbessern.

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 blinde Nutzer mit Screen-Readern ebenso wie 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. Die bislang einzige öffentlich dokumentierte BFSG-Abmahnwelle rollte bereits im August 2025. Für die behördliche Seite gibt es seit dem 26. September 2025 eine eigene Adresse: die Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF) mit Sitz in Magdeburg, eine gemeinsame Anstalt aller Bundesländer. Am 29. Januar 2026 hat sie ihre Marktüberwachungsstrategien beschlossen — und die sind der eigentlich interessante Teil.

Die MLBF arbeitet ausdrücklich zweigleisig: reaktiv auf Anträge und Beschwerden hin, und aktiv, also anlassunabhängig. Für webbasierte Dienstleistungen setzt sie dabei auf automatisierte Vorprüfungen mit technischer Prüfsoftware, um den Markt in der Breite zu erfassen. Für einen Shop heißt das im Klartext: Du kannst gescannt werden, ohne dass sich jemals jemand über dich beschwert hat.

Priorisiert wird nach Relevanz für die autonome Lebensführung, nach Reichweite, nach Auffälligkeiten in der Vergangenheit und nach Kooperationsbereitschaft. Dass die Behörde arbeitsfähig ist, zeigt auch ihr im Juni 2026 konstituierter Beirat, in dem unter anderem DIHK, ZDH und Bitkom sitzen.

Zwei Dinge sind dabei ehrlicherweise noch offen. Erstens: Öffentlich dokumentierte Einzelbußgelder nach dem BFSG sind auch im August 2026 nicht bekannt. Der Rahmen steht, die Praxis ist jung. Die MLBF sagt selbst, dass ihr für die laufende Strategieperiode noch die historischen Daten für quantitative Kontrollziele fehlen und der Fokus zunächst auf Reaktionsfähigkeit und dem Aufbau einer Datenbasis liegt. Das ist keine Entwarnung, sondern eine Beschreibung der Aufbauphase.

Zweitens: Ob BFSG-Verstöße nach § 3a UWG von Wettbewerbern abmahnbar sind, hat bis August 2026 noch kein Gericht entschieden. Als Fingerzeig gilt die BGH-Linie zur UWG-Abmahnbarkeit von DSGVO-Verstößen — ein Präzedenzfall für das BFSG ist das aber nicht. Wer auf diese Lücke setzt, wettet gegen eine Rechtsfrage, die jederzeit gegen ihn ausgehen kann.

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, die Dienstleistungen anbieten, sind ausgenommen. Die Definition in § 2 Nummer 17 BFSG ist präziser, als sie meist zitiert wird: weniger als zehn Beschäftigte — und entweder ein Jahresumsatz von höchstens 2 Millionen Euro oder eine Jahresbilanzsumme von höchstens 2 Millionen Euro. Umsatz und Bilanzsumme sind also Alternativen: Ein Shop mit 2,5 Millionen Euro Umsatz, aber einer Bilanzsumme unter 2 Millionen und neun Beschäftigten bleibt Kleinstunternehmen. Wichtig außerdem: Die Ausnahme gilt nur für Dienstleistungen, nicht für Produkte.

Ein weit verbreitetes Missverständnis sind die Übergangsbestimmungen in § 38 BFSG, aus denen gern ein „Wir haben ja bis 2030" wird.

Sie besagen: Dienstleistungen dürfen bis zum 27. Juni 2030 weiter unter Einsatz von Produkten erbracht werden, die vor dem 28. Juni 2025 rechtmäßig im Einsatz waren; vor diesem Stichtag geschlossene Verträge laufen bis zum Vertragsende, längstens ebenfalls bis 27. Juni 2030; Selbstbedienungsterminals dürfen bis zum Ende ihrer wirtschaftlichen Nutzungsdauer laufen, maximal 15 Jahre ab Ingebrauchnahme. Für die Website deines Shops verlängert das keine einzige Frist.

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.

BFSG-Checkliste für Shopware 6: die 10 Punkte

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>

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.
  • Die Bedienelemente sind eindeutig beschriftet — „Auswahl bestätigen" statt „OK".

Ein Hinweis zur Abgrenzung: Dass der „Alle akzeptieren"-Button nicht visuell bevorzugt sein darf, ist keine WCAG-Anforderung, sondern Einwilligungsrecht nach DSGVO und § 25 TDDDG. Beide Regelwerke treffen im selben Banner aufeinander — geprüft wird aber getrennt.

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. Informationen zur Barrierefreiheit bereitstellen

An diesem Punkt bauen die meisten Shops das falsche Dokument. Die „Erklärung zur Barrierefreiheit" mit Konformitätsstand, begründeten Ausnahmen und Prüfdatum stammt aus dem Behördenrecht (BGG/BITV) und gilt für öffentliche Stellen. Für einen Online-Shop verlangt § 14 Absatz 1 BFSG stattdessen die Informationen nach Anlage 3 Nummer 1 BFSG. Nichtkonformität musst du dort ausdrücklich nicht angeben und begründen.

Pflichtbestandteile sind:

  • eine allgemeine Beschreibung der Dienstleistung in einem barrierefreien Format
  • Beschreibungen und Erläuterungen, die zum Verständnis der Durchführung erforderlich sind
  • eine Beschreibung, wie die Dienstleistung die Barrierefreiheitsanforderungen erfüllt — hier darfst du dich auf angewandte harmonisierte Normen berufen
  • die Angabe der zuständigen Marktüberwachungsbehörde, also der MLBF (die Schlichtungsstelle gehört ausdrücklich nicht hierher)

Das Gesetz verortet diese Angaben in den AGB „oder auf andere deutlich wahrnehmbare Weise". Praktikabel ist eine eigene Seite „Barrierefreiheit", verlinkt in Kopf- und Fußzeile. Und das ist keine Formalie: Die Prüfung genau dieser Informationen ist ein wesentlicher Bestandteil der formalen Überwachung durch die MLBF — es ist der Punkt, an dem ein Shop bei einer automatisierten Vorprüfung als Erstes auffällt.

10. Automatisierte und manuelle Prüfung kombinieren

Automatisierte Tools prüfen zuverlässig nur einen Teil der Anforderungen: Sie decken rund ein Fünftel bis ein Drittel der WCAG-Erfolgskriterien maschinell ab — je nach Zählweise fällt der Wert höher aus, wenn man statt der Kriterien das Volumen der tatsächlich gefundenen Fehler zählt (Deque, Automated Accessibility Coverage Report). Für den Rest — Tastaturbedienung, Fokusreihenfolge, Verständlichkeit von Fehlermeldungen — braucht es Menschen. Eine belastbare Prüfung kombiniert deshalb 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

BFSG in Shopware 6: die typischen Fallstricke

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

Custom Themes

Das Standard-Theme (Storefront) ist solide aufgestellt — seit Shopware 6.7 sind die Accessibility-Verbesserungen (Skip-Links, korrektes Listen-Markup in Listing und Warenkorb, präzisere Formular-Fehlermeldungen, Alt-Texte für Symbol-Buttons) standardmäßig aktiv, die in 6.6 noch hinter einem Feature-Flag lagen. Aktuell ist der 6.7er-Zweig (Stand August 2026: 6.7.13.0 vom 5. August 2026); die nächste Major-Version 6.8 ist auf 2027 verschoben — ein Shop auf 6.7 bleibt also auf absehbare Zeit der aktuelle Stand und braucht die Barrierefreiheit nicht auf ein kommendes Major zu vertagen.

Ein aktuelles Shopware allein löst das Thema aber nicht: Custom Themes brechen die Barrierefreiheit häufig. Typische Defekte, die uns in der Shopware-Entwicklung begegnen: 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 %}

Overlay- und Toolbar-Plugins

Im Shopware Store finden sich mehrere Barrierefreiheits-Toolbars und Overlay-Erweiterungen, aktiv gepflegt und teils kostenlos. Sie legen dem Shop eine Bedienleiste über: Schrift vergrößern, Kontraste umschalten, Vorlesefunktion. Für manche Nutzergruppen ist das ein echter Komfortgewinn, und als Ergänzung spricht nichts dagegen.

Als Compliance-Strategie funktioniert es nicht. Ein Overlay ändert nichts am Quellcode darunter: Ein Bild ohne Alt-Text bleibt ohne Alt-Text, ein Modal ohne Focus-Trap bleibt eine Falle, ein Custom-Radio-Button ohne Rolle bleibt für den Screen-Reader unsichtbar. Genau das prüft eine automatisierte Vorprüfung der MLBF, und genau da findet sie die Fehler weiterhin. Fachleute aus der Accessibility-Szene warnen seit Jahren vor den Versprechen der Overlay-Anbieter; das Overlay Fact Sheet bündelt diese Kritik und hält fest, dass Overlays keine Konformität garantieren können.

Die Reihenfolge ist also: erst die Barrieren im Theme und in den Templates beseitigen, dann optional eine Toolbar als Zusatzangebot. Nicht umgekehrt.

Tools für den BFSG-Audit

Kostenlose Tools

ToolTypStärke
axe DevTools (Free)Browser-ExtensionPräzise WCAG-Prüfung, wenig False Positives
WAVEBrowser-ExtensionVisuelle Fehlerdarstellung
LighthouseChrome DevToolsSchneller Überblick, CI/CD-Integration
NVDAScreen-ReaderRealer Nutzertest (Windows)
Colour Contrast AnalyserDesktop-AppPixelgenaue Kontrastprüfung

Kostenpflichtige Tools

Die Preise der Enterprise-Werkzeuge hängen stark von Seitenzahl und Funktionsumfang ab und werden überwiegend individuell kalkuliert — die folgenden Angaben sind Einordnung, keine Preisliste.

ToolPreis abStärke
axe Monitorauf AnfrageAutomatisiertes Crawling ganzer Shops
Siteimproveauf AnfrageEnterprise-Monitoring mit Dashboard
Pope Techab ca. 25 $/MonatWAVE-basiertes Monitoring, kostenlos bis 25 Seiten

BFSG-Verstoß: Bußgeld, Untersagung, Abmahnung

Die Sanktionen laufen auf drei Ebenen.

Bußgelder

Am Anfang steht kein Bußgeld, sondern ein Stufenmodell: Die Behörde fordert zunächst zur Korrektur innerhalb einer Frist auf. Bleibt das folgenlos, kann sie die Erbringung der Dienstleistung einschränken oder untersagen. Erst danach wird es finanziell.

Der Rahmen steht in § 37 BFSG und ist zweistufig: Wer eine nicht barrierefreie Dienstleistung anbietet oder erbringt, riskiert eine Geldbuße bis zu 100.000 Euro. Für die übrigen Verstöße — etwa fehlende oder falsche Informationen nach Anlage 3 — liegt die Grenze bei 10.000 Euro. Beide Beträge sind Obergrenzen, keine Regelsätze.

Abmahnungen

In der Praxis begegnet dir eher Post von einer Kanzlei als von der Behörde. Wettbewerbsrechtliche Abmahnungen wegen BFSG-Mängeln werden seit Sommer 2025 verschickt — ob sie berechtigt sind, ist die offene Frage aus dem ersten Kapitel: Ob ein BFSG-Verstoß über § 3a UWG abmahnfähig ist, hat bis August 2026 kein Gericht entschieden. Die einzige öffentlich aufgearbeitete Welle aus dem August 2025 hielten Fachanwälte für unwirksam, unter anderem weil ein konkretes Wettbewerbsverhältnis fehlte und keine Unterlassungserklärung gefordert wurde.

Belastbare Zahlen zu Abmahnkosten gibt es für das BFSG bislang nicht; in dem dokumentierten Fall lag der geforderte Kostenersatz im niedrigen dreistelligen Bereich. Verlass dich trotzdem nicht darauf: Barrieren lassen sich mit Standard-Tools in Minuten dokumentieren, der Aufwand für den Abmahnenden ist also gering. Das ist der eigentliche Unterschied zu früheren Abmahnwellen.

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 und eine logische Tab-Reihenfolge verbessern die mobile Nutzererfahrung. Zur Zielgröße: WCAG 2.2 verlangt auf Stufe AA mindestens 24×24 CSS-Pixel (Kriterium 2.5.8); die oft zitierten 44×44 Pixel sind die AAA-Empfehlung und eine gute Praxis, keine Pflicht. Google beschreibt die Page Experience seit 2023 nicht mehr als einzelnes Ranking-Signal — die Nutzersignale dahinter wirken trotzdem.

Fazit

Das BFSG gilt seit Juni 2025, und im zweiten Geltungsjahr ist die Durchsetzung Realität: Seit Januar 2026 prüft die MLBF nach beschlossener Strategie — auch anlassunabhängig und automatisiert —, Abmahnungen laufen seit dem Sommer 2025. 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. Die Umsetzung im Theme ist dann klassische Shopware Entwicklung, kein Konfigurationsjob.


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.

Wie wir Shops bauen und betreiben, steht auf unserer Seite zur Shopware-Agentur; den breiteren Rahmen dazu findest du bei unseren E-Commerce-Leistungen. Du erreichst uns über das Kontaktformular oder direkt per E-Mail.

Bereit für den nächsten Schritt?

Setz das Gelernte direkt um – wir unterstützen dich dabei.

Weitere Beiträge