WooCommerce und BFSG: Deinen WordPress-Shop barrierefrei machen
WooCommerce: Barrierefreiheit im WordPress-Ökosystem
WooCommerce ist mit einem Marktanteil von über 35 Prozent das meistgenutzte Shop-System weltweit. Es profitiert von WordPress' grundlegender Barrierefreiheit, bringt aber eigene Herausforderungen: Produktseiten mit variablen Attributen, ein mehrstufiger Checkout-Prozess, Warenkorb-Updates per AJAX und zahlreiche Drittanbieter-Plugins. Jede dieser Komponenten muss einzeln auf Barrierefreiheit geprüft werden.
Seit dem Inkrafttreten des Barrierefreiheitsstärkungsgesetzes (BFSG, § 1 Abs. 2) im Juni 2025 gelten verbindliche Anforderungen für digitale Handelsplattformen. Wer mit WooCommerce Produkte oder Dienstleistungen an Verbraucher verkauft, muss die Konformität mit den WCAG 2.2 AA-Richtlinien sicherstellen. Das klingt abstrakt, betrifft aber ganz konkrete Elemente deines Shops: vom Produktbild-Alt-Text bis zum Bestell-Button.
In diesem Leitfaden zeigen wir dir Schritt für Schritt, wie du deinen WooCommerce-Shop barrierefrei machst, welche Themes und Plugins helfen und wo die häufigsten Stolperfallen lauern. Die gute Nachricht: Mit der richtigen Herangehensweise ist ein barrierefreier WooCommerce-Shop kein Hexenwerk.
WordPress-Themes mit guter Barrierefreiheit
Das Theme ist das Fundament deiner Barrierefreiheit. Wenn das Theme bereits grundlegende Standards verletzt, kämpfst du bei jedem Plugin und jeder Anpassung gegen Windmühlen. WordPress kennzeichnet Themes, die bestimmte Barrierefreiheits-Standards erfüllen, mit dem Tag "Accessibility Ready" im Theme-Verzeichnis. Weitere Informationen finden Sie im BFSG-Glossar.
Twenty Twenty-Four (und neuere Standard-Themes): Die offiziellen WordPress-Themes ab Twenty Twenty-One setzen konsequent auf semantisches HTML, korrekte Heading-Hierarchie und Tastatur-Navigation. Twenty Twenty-Four nutzt den Full Site Editor und liefert von Haus aus Skip-Links, ARIA-Landmarks und ein Farbschema mit ausreichendem Kontrast (WCAG SC 1.4.3). Für WooCommerce-Shops sind sie ein solider Startpunkt.
Flavor: Das Theme Flavor wurde speziell für WooCommerce entwickelt und bringt überdurchschnittliche Barrierefreiheit mit. Fokus-Indikatoren sind sichtbar, die Shop-Seiten nutzen semantische Regionen, und die Produktgalerien sind per Tastatur bedienbar. Dennoch ersetzt kein Theme die manuelle Pflege deiner Inhalte: Alt-Texte, Überschriften-Struktur und Formularbeschriftungen bleiben deine Verantwortung.
Storefront: Das offizielle WooCommerce-Theme von Automattic ist bewusst schlank gehalten und folgt WordPress-Coding-Standards. Es bietet solide Grundlagen für Barrierefreiheit, hat aber bei Produktfiltern und der mobilen Navigation Schwächen. Teste diese Bereiche besonders gründlich.
Vermeide Multi-Purpose-Themes wie Flavor Theme Flavor oder ähnliche Theme-Builder mit überladenem Frontend. Mehr JavaScript bedeutet mehr potenzielle Barrierefreiheits-Probleme. Wenn du ein Theme wechselst, führe danach immer einen kompletten Barrierefreiheits-Scan durch.
Produktseiten barrierefrei gestalten
Produktseiten sind das Herzstück deines Shops. Hier entscheiden Kunden, ob sie kaufen. Wenn diese Seiten nicht zugänglich sind, verlierst du nicht nur potenzielle Kunden mit Behinderungen, sondern verstößt auch gegen § 3 BFSG.
Alt-Texte für alle Produktbilder: Jedes Produktbild und jedes Galerie-Bild braucht einen beschreibenden Alt-Text (WCAG SC 1.1.1). Beschreibe das Produkt konkret: "Blaues Herren-T-Shirt aus Bio-Baumwolle, Frontansicht" statt "Produkt-Bild". Erfahre mehr in unserem Leitfaden zu Alt-Texten.
Produktvarianten per Tastatur bedienbar machen: Varianten wie Größe und Farbe müssen vollständig per Tastatur auswählbar sein (WCAG SC 2.1.1, Tastaturzugänglichkeit). Das Standard-WooCommerce-Dropdown funktioniert grundsätzlich, aber viele Shops ersetzen es durch visuelle Farbfelder (Color Swatches). Diese sind häufig nur per Maus bedienbar. Prüfe mit der Tab-Taste, ob du jede Variante erreichen und mit Enter auswählen kannst.
Preisinformationen zugänglich auszeichnen: Preise dürfen nicht nur visuell hervorgehoben sein. Durchgestrichene Originalpreise brauchen eine Screenreader-lesbare Kennzeichnung, zum Beispiel:
<span class="screen-reader-text">Ursprünglicher Preis:</span>
<del>49,99 €</del>
<span class="screen-reader-text">Reduzierter Preis:</span>
<ins>39,99 €</ins>
"In den Warenkorb"-Button: Der Button muss einen eindeutigen, zugänglichen Namen haben. In Produktlisten, wo mehrere "In den Warenkorb"-Buttons erscheinen, muss jeder per aria-label dem jeweiligen Produkt zugeordnet sein (WCAG SC 2.4.6):
<button aria-label="Blaues T-Shirt in den Warenkorb legen">
In den Warenkorb
</button>
Warenkorb-Updates mit ARIA-Live-Regions
Einer der kritischsten Bereiche in WooCommerce ist der dynamische Warenkorb. Wenn ein Nutzer ein Produkt hinzufügt, aktualisiert WooCommerce den Mini-Warenkorb im Header per AJAX, ohne die Seite neu zu laden. Für sehende Nutzer ist das praktisch. Für Screenreader-Nutzer passiert: nichts. Sie bekommen keine Rückmeldung, ob die Aktion erfolgreich war.
Die Lösung heißt ARIA-Live-Regions (WCAG SC 4.1.3, Statusmeldungen). Eine aria-live-Region informiert assistive Technologien über dynamische Änderungen, ohne den Fokus zu verschieben:
<!-- Versteckte Live-Region im Header -->
<div aria-live="polite" aria-atomic="true" class="screen-reader-text">
Warenkorb: 3 Artikel, Gesamtsumme 89,97 €
</div>
<!-- Nach dem Hinzufügen per JS aktualisieren: -->
document.querySelector('[aria-live="polite"]')
.textContent = 'Produkt hinzugefügt. Warenkorb: 4 Artikel, Gesamtsumme 129,96 €';
Verwende aria-live="polite" für Warenkorb-Updates, damit die Meldung den Nutzer nicht unterbricht. Für kritische Fehler (Produkt nicht verfügbar, Zahlungsfehler) nutze aria-live="assertive".
Das Standardverhalten von WooCommerce setzt dies leider nicht um. Du kannst das mit einem kleinen Custom-Snippet in deiner functions.php oder einem Mini-Plugin nachrüsten.
Checkout und Warenkorb barrierefrei gestalten
Der WooCommerce-Standard-Checkout ist brauchbar, aber oft durch Themes oder Checkout-Plugins überschrieben. Der neue WooCommerce Blocks-Checkout ist in vielen Bereichen barrierefreier als der klassische Shortcode-Checkout. Wenn du die Wahl hast, setze auf die Blocks-Variante.
Prüfe folgende Punkte systematisch:
Formularfelder: Sind alle Felder mit zugehörigen <label>-Elementen verknüpft (WCAG SC 1.3.1)? Placeholder-Text allein ist keine gültige Beschriftung. Erfahre mehr in unserem Artikel zu barrierefreien Formularen.
Fehlermeldungen: Werden Fehler (falsche PLZ, fehlende Pflichtfelder) zugänglich angezeigt? Die Fehlermeldung muss programmatisch mit dem betroffenen Feld verknüpft sein (aria-describedby) und der Fokus sollte zum ersten Fehler springen (WCAG SC 3.3.1).
Coupon-Eingabe: Das Coupon-Feld ist in vielen Themes hinter einem Toggle-Link versteckt. Prüfe, ob dieser Link per Tastatur erreichbar ist und ob das aufklappende Feld korrekt den Fokus erhält.
Zahlungsauswahl: Payment-Gateways (PayPal, Stripe, Klarna) rendern eigene iframes und Formulare. Teste jede Zahlungsmethode separat mit Tastatur und Screenreader. Besonders Stripe Elements und PayPal Checkout haben in der Vergangenheit Barrierefreiheits-Probleme gehabt.
Fortschrittsanzeige: Wenn dein Checkout mehrstufig ist (Adresse, Versand, Zahlung), muss der aktuelle Schritt für Screenreader erkennbar sein. Nutze aria-current="step" für den aktiven Schritt.
Schritt-für-Schritt: WooCommerce Accessibility Audit
Ein systematisches Audit stellt sicher, dass du keine Bereiche übersiehst. Gehe in dieser Reihenfolge vor:
Schritt 1: Automatisierten Scan durchführen. Starte mit einem bf-check.de Scan deiner Startseite, einer Produktseite, der Shop-Seite und des Checkouts. Automatisierte Tools finden circa 30-40 % aller Barrieren, insbesondere fehlende Alt-Texte, Kontrastprobleme und fehlende Labels.
Schritt 2: Tastatur-Test. Navigiere deinen gesamten Kaufprozess nur mit der Tastatur: Produkt finden, Variante wählen, in den Warenkorb legen, Checkout abschließen. Achte auf: Ist der Fokus jederzeit sichtbar (SC 2.4.7)? Kannst du überall hin und auch wieder weg (keine Tastaturfallen, SC 2.1.2)?
Schritt 3: Screenreader-Test. Teste mit NVDA (kostenlos, Windows) oder VoiceOver (macOS/iOS) die kritischen Seiten. Wird der Produktname vorgelesen? Wird der Preis korrekt angekündigt? Bekommst du eine Bestätigung nach "In den Warenkorb"?
Schritt 4: Plugin-Audit. Liste alle aktiven Plugins auf, die Frontend-Elemente rendern. Teste jedes einzeln, indem du es deaktivierst und die Barrierefreiheit vorher/nachher vergleichst.
Schritt 5: Content-Prüfung. Überprüfe stichprobenartig Produktbeschreibungen auf Überschriften-Hierarchie, Listenstruktur und Linktexte. "Hier klicken" oder "Mehr erfahren" ohne Kontext verletzt WCAG SC 2.4.4.
Schritt 6: Dokumentation. Halte alle Ergebnisse schriftlich fest. Ein BFSG-konformer WordPress-Shop braucht einen lückenlosen Audit-Trail.
Kritische WooCommerce-Plugins und die Plugin-Audit-Checkliste
Jedes Plugin, das Frontend-Elemente ändert, kann Barrierefreiheit brechen. Das ist das größte Risiko im WooCommerce-Ökosystem: Du baust einen sauberen, barrierefreien Shop und dann installiert jemand ein Plugin, das alles zunichtemacht.
Hier die häufigsten Problemkandidaten:
YITH WooCommerce Wishlist: Fügt einen "Zur Wunschliste"-Button hinzu, der häufig kein aria-label hat und nur ein Herz-Icon ohne Textbeschriftung zeigt. Lösung: Custom CSS .screen-reader-text-Klasse ergänzen oder das Plugin konfigurieren, Text statt Icon zu zeigen.
WooCommerce Product Filter / FacetWP: Filter-Plugins ersetzen Seiteninhalte dynamisch, oft ohne aria-live-Region. Screenreader-Nutzer merken nicht, dass sich die Produktliste geändert hat. Prüfe, ob nach dem Filtern eine Statusmeldung erscheint (SC 4.1.3).
Variation Swatches: Ersetzen Standard-Dropdowns durch visuelle Farbfelder oder Bildauswahlen. Problem: Oft nicht per Tastatur bedienbar (SC 2.1.1), fehlende Fokus-Indikatoren, keine role="radiogroup"-Semantik.
Quick View Plugins: Öffnen Produktdetails in einem Modal. Modals sind einer der häufigsten Barrierefreiheits-Fehler: Fokus wird nicht ins Modal verschoben, Escape schließt nicht, Hintergrund ist weiterhin per Tab erreichbar. Vermeide Quick View oder stelle sicher, dass das Plugin die WAI-ARIA Dialog-Pattern korrekt implementiert.
WPForms / Contact Form 7 / Gravity Forms: Kontaktformulare und Bestellformulare müssen korrekte Labels, Fehlermeldungen und Pflichtfeld-Kennzeichnungen haben. WPForms schneidet bei Barrierefreiheit mittelmäßig ab. Gravity Forms bietet seit Version 2.5 deutlich verbesserte ARIA-Attribute. Lies dazu unseren Artikel zu barrierefreien Formularen.
Slider-Plugins (Slider Revolution, MetaSlider): Automatisch rotierende Slider verstoßen gegen WCAG SC 2.2.2 (Pause, Stop, Hide). Wenn du einen Slider verwenden musst, stelle sicher, dass er pausierbar ist und Steuerelemente per Tastatur bedienbar sind.
Plugin-Audit-Checkliste
Prüfe für jedes Frontend-Plugin:
- Sind alle interaktiven Elemente per Tastatur erreichbar (SC 2.1.1)?
- Haben Icons und Buttons beschreibende Texte oder aria-labels (SC 1.1.1, SC 4.1.2)?
- Werden dynamische Änderungen per aria-live angekündigt (SC 4.1.3)?
- Sind Fokus-Indikatoren sichtbar (SC 2.4.7)?
- Werden Modals korrekt gehandhabt (Fokus-Trap, Escape zum Schließen)?
- Funktioniert das Plugin mit 200% Zoom ohne Überlappungen (SC 1.4.4)?
- Bleibt der Farbkontrast bei Plugin-eigenen UI-Elementen ausreichend (SC 1.4.3)?
Teste nach jeder Plugin-Installation die betroffenen Seiten mit dem bf-check.de Scanner. Dokumentiere das Ergebnis. Wenn ein Plugin durchfällt und der Entwickler nicht nachbessert, suche eine barrierefreie Alternative.
Häufige Fehler bei WooCommerce-Barrierefreiheit
Aus hunderten Shop-Audits kennen wir die typischen Stolperfallen:
Fehlende Skip-Links: Gerade bei Shops mit großer Navigation und vielen Kategorien ist ein Skip-Link ("Zum Inhalt springen") essenziell (SC 2.4.1). Viele WooCommerce-Themes vergessen ihn.
Produktbilder ohne Alt-Text: WooCommerce zieht den Alt-Text aus der WordPress-Mediathek. Wenn dort nichts hinterlegt ist, bleibt das Bild für Screenreader unsichtbar. Bei 500 Produkten mit je 3 Bildern sind das 1.500 potenzielle Verstöße.
Warenkorb-Badge ohne Kontext: Die rote Zahl am Warenkorb-Icon ("3") sagt einem Screenreader nichts. Ergänze: aria-label="Warenkorb, 3 Artikel".
Checkout ohne Fehler-Fokus: Nach einem Formularfehler scrollen viele Themes zum Fehler, setzen aber nicht den Fokus. Screenreader-Nutzer wissen nicht, was passiert ist.
Zoom bricht das Layout: Viele WooCommerce-Themes brechen bei 200 % Browser-Zoom, weil Produktgrids und Checkout-Layouts nicht responsive genug sind (SC 1.4.4).
Dieser Artikel ersetzt keine Rechtsberatung. Bei konkreten Fragen zur BFSG-Konformität wende dich an eine qualifizierte Rechtsberatung.
Häufig gestellte Fragen
Weiterlesen
Ist deine Webseite BFSG-konform?
Finde es in 30 Sekunden heraus – kostenloser Schnellcheck mit sofortigem Ergebnis.
Jetzt kostenlos prüfen →