WooCommerce ist weder barrierefrei noch nicht barrierefrei. Entscheidend ist, was Ihr Shop im Browser ausliefert: Theme, Page-Builder, Plugins und Produktdaten. In WooCommerce-Shops entstehen die meisten Barrieren an fünf Stellen – Cookie-Banner, Variantenauswahl, nachladende Filter und Warenkörbe, Menüs und der Checkout mit eingebetteten Zahlungsfeldern. Diese Seite trennt, was WordPress und WooCommerce mitbringen, von dem, was Ihre Aufgabe bleibt, und nennt die Stellen, die Sie zuerst prüfen sollten.
Gilt das BFSG für Ihren WooCommerce-Shop?
Wenn Sie über WooCommerce an Verbraucherinnen und Verbraucher verkaufen, erbringen Sie eine „Dienstleistung im elektronischen Geschäftsverkehr“ (§ 1 Abs. 3 Nr. 5 BFSG). Dafür gilt das Barrierefreiheitsstärkungsgesetz seit dem 28. Juni 2025 [1]. Es setzt den European Accessibility Act um; wer in andere EU-Länder verkauft, trifft dort auf vergleichbare nationale Gesetze [2].
Ausgenommen sind Kleinstunternehmen, die Dienstleistungen erbringen: weniger als zehn Beschäftigte und höchstens 2 Mio. € Jahresumsatz oder Jahresbilanzsumme (§ 2 Nr. 17, § 3 Abs. 3 BFSG) [1]. Beide Bedingungen müssen erfüllt sein. Wie Sie Beschäftigte zählen und was in einer Unternehmensgruppe gilt, steht auf unserer Seite zur Ausnahme für Kleinstunternehmen. Ein reiner B2B-Shop, der nur an Gewerbekunden verkauft, erbringt keine Dienstleistung für Verbraucher. Wer beides macht, sollte den Verbraucherteil als erfasst behandeln.
Anwendungsbereich, Marktüberwachung und Pflichtinformationen erklärt unser Überblick BFSG für Onlineshops. Vieles auf dieser Seite gilt für jede WordPress-Website – den Blick auf WordPress insgesamt finden Sie unter WordPress-Barrierefreiheit und das BFSG.
Was WooCommerce mitbringt – und was nicht
Sie bekommen:
- Warenkorb- und Checkout-Blöcke. Seit WooCommerce 8.3 sind die blockbasierten Warenkorb-, Kassen- und Bestellbestätigungsseiten bei Neuinstallationen Standard [3]. Sie verwenden native Formularelemente mit sichtbaren Beschriftungen. Ältere Shops behalten den klassischen Shortcode-Checkout, bis jemand umstellt.
- Einen Core mit WCAG 2.2 AA als Maßstab. Nach den WordPress Accessibility Coding Standards soll Code in WordPress-Core, auf WordPress.org und in offiziellen Plugins WCAG 2.2 auf Stufe AA erfüllen [4].
- Themes mit dem Tag „accessibility-ready“. Im Theme-Verzeichnis von WordPress.org bekommen Themes dieses Tag erst nach einer manuellen Prüfung durch das Accessibility-Team. Geprüft werden unter anderem Skip-Link, Tastaturbedienung, sinnvolle Überschriftenstruktur, beschriftete Formularfelder und ausreichende Kontraste [5].
- Native Variantenauswahl. Ohne Zusatz-Plugin zeigt WooCommerce Varianten als Auswahlliste (
<select>). Die ist per Tastatur bedienbar und für Screenreader verständlich.
Sie bekommen nicht:
- Eine Garantie für Ihr Theme. „accessibility-ready“ gilt für das geprüfte Theme im Auslieferungszustand, nicht für Ihr Child-Theme, Ihre Farben oder Ihre Anpassungen. Kauf-Themes von Marktplätzen außerhalb von WordPress.org durchlaufen diese Prüfung gar nicht.
- Kontrolle über Page-Builder-Ausgaben. Was Elementor, Divi oder WPBakery ausgeben, hängt vom gewählten Widget und seiner Konfiguration ab.
- Barrierefreie Plugins. Jedes Plugin mit Frontend-Ausgabe bringt eigenes Markup und eigenes JavaScript mit. Das Plugin-Verzeichnis prüft sie nicht auf Barrierefreiheit.
- Brauchbare Alt-Texte. Die Alternativtexte kommen aus der Mediathek oder aus Ihrem Produktimport. Fehlen sie, zeigen viele Themes den Dateinamen oder den Produktnamen. Beides beschreibt das Bild nicht.
Was wir auf WooCommerce-Shops finden
Cookie-Banner, die vor allem anderen stehen
Das Consent-Tool ist das erste Element auf jeder Seite. Ein Fehler dort wirkt also im ganzen Shop. Typisch: Der Fokus springt nicht in den Dialog, man kann dahinter weiter tabben, „Ablehnen“ ist ein kontrastschwacher Textlink, oder das Symbol zum erneuten Öffnen hat keinen zugänglichen Namen. Ob das bei Borlabs Cookie, Real Cookie Banner, Complianz oder einem anderen Tool passiert, hängt stark von Version, Layoutwahl und eigenem CSS ab – prüfen Sie Ihre Konfiguration, nicht die Demo des Anbieters.
Variantenauswahl als Farbfelder
Swatch-Plugins ersetzen die native Auswahlliste durch Farb- oder Bildfelder. Oft sind das div- oder span-Elemente, die sich nicht fokussieren lassen und keinen Namen haben. Die aktive Auswahl ist nur an einem Rahmen zu erkennen, „ausverkauft“ nur an einer Durchstreichung. Wenn sich danach Preis oder Lieferbarkeit ändern, bekommt ein Screenreader davon nichts mit.
Warenkorb, Mini-Cart und Filter ohne Rückmeldung
„In den Warenkorb“ per AJAX ist bequem, bleibt für viele Nutzer aber stumm: keine Statusmeldung, und der Off-Canvas-Mini-Cart öffnet sich, ohne dass der Fokus hineinwandert. AJAX-Filter laden die Produktliste neu, sagen aber nicht an, wie viele Treffer es gibt. Danach landet der Fokus oft am Seitenanfang. Preisschieberegler funktionieren häufig nur mit Ziehen.
Mega-Menüs aus dem Page-Builder
Untermenüs öffnen sich nur beim Hovern. Der Auslöser ist ein Link statt eines Buttons und hat kein aria-expanded. Im mobilen Off-Canvas-Menü bleibt der Tastaturfokus hinter dem geöffneten Menü – wer mit der Tastatur navigiert, tabbt durch Links, die er nicht sieht.
Slider und Produktgalerien
Hero-Slider laufen automatisch ohne Pause-Schaltfläche. Pfeile und Punkte sind Symbole ohne Beschriftung. In Galerie-Lightboxen fehlt manchmal ein Weg zurück per Escape, oder der Fokus bleibt nach dem Schließen verloren.
Checkout mit Zahlungs-Iframes und Pflicht-Checkboxen
Zahlungsanbieter binden Kartenfelder und Express-Buttons als Iframes ein. Wenn die keinen title haben oder die Fokusreihenfolge aus dem Iframe heraus nicht stimmt, bricht der Kauf genau dort ab. Im klassischen Shortcode-Checkout stehen Fehlermeldungen je nach Version und Theme gesammelt oben statt am Feld. Checkout-Feld-Editoren entfernen gern die autocomplete-Attribute. Pflicht-Checkboxen aus Rechtstext-Plugins wie Germanized oder German Market brauchen eine korrekt verknüpfte Beschriftung und eine verständliche Fehlermeldung.
Wo Sie zuerst prüfen sollten
| Kriterium | Warum bei WooCommerce | Automatisierbar |
|---|---|---|
| 2.1.1 Tastatur (A) | Swatches, Mega-Menüs, Preisschieberegler | Teilweise automatisiert |
| 2.1.2 Keine Tastaturfalle (A) | Cookie-Dialog, Lightbox, Zahlungs-Iframe | Teilweise automatisiert |
| 2.4.3 Fokus-Reihenfolge (A) | Mini-Cart, Off-Canvas-Menü, Filter | Teilweise automatisiert |
| 2.4.7 Fokus sichtbar (AA) | Theme-CSS mit outline: none | Teilweise automatisiert |
| 4.1.2 Name, Rolle, Wert (A) | Swatches, Icon-Buttons, Menü-Toggles | Teilweise automatisiert |
| 4.1.3 Statusmeldungen (AA) | AJAX-Warenkorb, Filtertreffer | Nur manuell |
| 3.3.1 Fehlererkennung (A) | Checkout-Fehler, Pflicht-Checkboxen | Nur manuell |
| 1.3.5 Eingabezweck bestimmen (AA) | Angepasste Checkout-Felder | Teilweise automatisiert |
| 1.1.1 Nicht-Text-Inhalt (A) | Produktbilder aus Import | Teilweise automatisiert |
| 1.4.3 Kontrast (Minimum) (AA) | „Ablehnen“-Links, Preis-Badges | Automatisiert |
„Automatisiert“ heißt: Eine Regel kann das Kriterium allein entscheiden. „Teilweise automatisiert“ heißt: Eine Regel findet einen Teil der Fehler, den Rest muss ein Mensch beurteilen. Alle Kriterien stehen in WCAG 2.2 AA, Kriterium für Kriterium.
Eine sinnvolle Reihenfolge
- Theme und Builder isolieren. Lassen Sie eine Staging-Kopie einmal mit einem Standard-Theme (Storefront oder ein aktuelles Twenty-Twenty-Theme) prüfen. Was dort verschwindet, kommt aus Ihrem Theme oder Builder.
- Cookie-Banner zuerst. Es steht auf jeder Seite. Eine Korrektur dort behebt einen Befund auf allen URLs.
- Die Kaufstrecke mit der Tastatur gehen. Startseite → Kategorie → Filter → Produkt → Variante → Warenkorb → Kasse → Zahlung im Testmodus. Die Startseite allein sagt wenig.
- Plugins inventarisieren. Listen Sie jedes Plugin mit Frontend-Ausgabe auf. Entscheiden Sie pro Plugin: korrigieren, ersetzen oder als bekannte Einschränkung dokumentieren. Fragen Sie Anbieter nach Testnachweisen statt nach einem Siegel.
- Alt-Texte an der Quelle reparieren. In der Mediathek oder im Import (CSV, WP All Import, Warenwirtschaft), nicht Seite für Seite.
- Nach jedem Update erneut prüfen. Zahlungs-, Filter- und Consent-Plugins aktualisieren sich oft. Ein regelmäßiger Crawl fängt Rückschritte ab, bevor Kunden sie melden.
Was Reviseberg auf WooCommerce-Shops prüft – und was Sie selbst testen
Reviseberg crawlt Ihren Shop einschließlich Kategorie- und Produktseiten und führt auf jeder Seite alle axe-core-Regeln in einer Desktop-Breite von 1280 Pixeln aus. Die Regeln, deren Ergebnis vom Layout abhängt – etwa Kontrast und Zielgröße –, laufen zusätzlich bei 360 Pixeln. Die Ergebnisse sind WCAG 2.2 A/AA und EN 301 549 zugeordnet. Befunde werden je Regel zu Issues zusammengefasst und danach sortiert, wie viele Punkte ihre Behebung bringt. Ein Fehler im Theme erscheint deshalb als ein Issue auf 400 Seiten und nicht als 400 Einzelbefunde.
Der Tastatur-Agent öffnet die Seiten einer Journey, die Sie festlegen – Kategorie, Produktseite, Warenkorb –, drückt auf jeder Tab, Umschalt+Tab und Escape und protokolliert jeden Schritt. Er meldet unerreichbare Elemente, verschwindenden oder unsichtbaren Fokus, fehlende Skip-Links und Tastaturfallen. Formulare füllt er nicht aus, und er bestellt nicht. Die Kassenschritte hinter einem gefüllten Warenkorb und das Zahlungs-Iframe gehen Sie also selbst. Der kostenlose Bericht umfasst bis zu 100 Seiten und den Tastatur-Agenten auf einer Seite Ihrer Wahl.
Selbst testen müssen Sie weiterhin: ob Alt-Texte das Bild sinnvoll beschreiben, ob Fehlermeldungen verständlich sind und wie sich der Shop mit Screenreader und Zoom verhält. Agenten für Screenreader, Zoom und Sprachsteuerung sind noch nicht gebaut. Für diese Kriterien gibt es geführte manuelle Tests in der Plattform, und ein Kriterium, das niemand geprüft hat, gilt als ungeprüft – nie als bestanden. Nichts wird automatisch in Ihren Shop eingespielt, und wir setzen kein Overlay-Skript ein.
Geschrieben, um nützlich zu sein, nicht als Rechtsberatung. Stand: 27. September 2026.