Ratgeber · WooCommerce & BFSG

WooCommerce barrierefrei machen: So wird Ihr Shop WCAG-konform

WooCommerce barrierefrei machen bedeutet mehr als ein Plugin zu installieren – denn WooCommerce ist selbst kein eigenständiges Shopsystem, sondern ein Plugin für WordPress. Barrierefreiheit hängt hier von drei unabhängigen Ebenen ab, die getrennt geprüft werden müssen: dem WooCommerce-Core mit seinen Blocks, dem WordPress-Theme und den zusätzlichen Plugins für Zahlungsarten, Swatches, Galerien oder Cookie-Consent. Ein Fehler kann aus jeder dieser drei Ebenen stammen – und genau das macht WooCommerce-Audits anders als bei geschlossenen Systemen wie Shopify.

Seit dem 28. Juni 2025 gilt in Deutschland das Barrierefreiheitsstärkungsgesetz (BFSG), faktisch mit dem Standard WCAG 2.1 AA. Die allgemeinen rechtlichen Grundlagen, die Kleinstunternehmen-Ausnahme und den zeitlichen Rahmen haben wir bereits im Pillar-Artikel „Onlineshop barrierefrei machen" ausführlich erklärt – hier geht es ausschließlich um das, was WooCommerce-Betreiber konkret anders machen müssen als Nutzer anderer Shopsysteme.

Die gute Nachricht vorweg: WooCommerce selbst hat 2024 sein Core- und Blocks-Frontend von der Agentur Equalize Digital gegen WCAG 2.2 AA prüfen lassen – das schließt den für das BFSG maßgeblichen Standard WCAG 2.1 AA automatisch mit ein – und ist laut eigenem Accessibility Conformance Report inzwischen weitgehend konform. Die schlechte Nachricht: Theme, Page-Builder und Drittanbieter-Plugins zerstören diese Basis in der Praxis sehr häufig wieder.

Dieser Ratgeber vertieft die Umsetzung. Die allgemeinen BFSG-Grundlagen – wer betroffen ist, welche Ausnahme gilt, was es kostet – finden Sie im Leitfaden „Onlineshop barrierefrei machen".

Welche drei Ebenen sind bei WooCommerce für Barrierefreiheit entscheidend?

Die erste Ebene ist WooCommerce selbst: Core-Templates, Checkout-Blocks, Produktfilter. Die zweite ist das WordPress-Theme, das Layout, Menüs und Fokus-Stile bestimmt. Die dritte sind Plugins – Swatches, Galerien, Cookie-Banner, Zahlungs-Gateways –, die zusätzliche Bedienelemente in den Shop einfügen. Bei einem Audit muss jede Ebene einzeln getestet werden, weil eine gut gemachte WooCommerce-Basis durch ein einziges schlecht programmiertes Plugin komplett unbrauchbar werden kann.

Wichtig ist außerdem, welche Theme-Architektur im Einsatz ist. Klassische PHP-Themes werden über den WordPress-Customizer bearbeitet, das Layout steckt fest codiert in PHP-Templates – ob Skip-Links, Landmarks und Tastaturnavigation korrekt implementiert sind, hängt allein vom jeweiligen Theme-Autor ab. Moderne Block- beziehungsweise FSE-Themes (Full Site Editing) werden dagegen im Site-Editor mit HTML-Block-Templates gebaut und erzeugen Skip-Links, Landmarks und Tastaturnavigation weitgehend automatisch über den WordPress-Core. Der Unterschied in der Grundqualität ist erheblich – die erste Frage in jedem WooCommerce-Audit sollte daher lauten, welche Theme-Architektur der Shop nutzt.

Ist der WooCommerce-Checkout barrierefrei?

Hier gibt es zwei technisch grundverschiedene Varianten, die vor jedem Audit geklärt werden müssen. Der moderne Cart & Checkout Block basiert auf der WooCommerce-Store-API, nutzt Gutenberg-Blocks mit HTML5-Semantik und ist seit WooCommerce ca. 8.3 bei Neuinstallationen Standard. WooCommerce selbst verknüpft hier Fehlermeldungen per ARIA mit den jeweiligen Feldern und nutzt aria-live-Regionen für Validierung und Summenänderungen. Der klassische Shortcode-Checkout ([woocommerce_checkout], Template checkout/form-checkout.php) läuft dagegen noch bei vielen älteren, produktiv laufenden Shops – seine Barrierefreiheit hängt vollständig vom Theme und den Plugins ab, die das Formular umstylen.

In der Praxis ist die häufigste Ursache für einen kaputten WooCommerce-Checkout gar nicht WooCommerce selbst, sondern ein Page-Builder wie Elementor, Divi oder WPBakery beziehungsweise ein Checkout-Field-Editor-Plugin. Sobald diese das Formular-Markup umbauen, gehen Label-Verknüpfungen, das aria-describedby für Fehlermeldungen und die Fokus-Reihenfolge häufig verloren – WooCommerce hat sie ursprünglich korrekt gesetzt, das überschreibende Plugin aber nicht nachgezogen.

Welche typischen Barrieren finden wir in WooCommerce-Shops?

Manche Probleme tauchen in fast jedem WooCommerce-Audit wieder auf, weil sie aus denselben wiederkehrenden Plugin- und Theme-Kombinationen stammen. Besonders häufig sind Farb- und Größen-Swatches, die als reine div- oder span-Elemente statt echter Radiobuttons gerendert werden, sowie der AJAX-Add-to-Cart-Mechanismus über WooCommerce-„Fragments": Wenn das Theme den aktualisierten Warenkorb-Zähler nicht in eine aria-live-Region einbettet, bekommen Screenreader-Nutzer nie eine Bestätigung, dass ein Produkt tatsächlich im Warenkorb gelandet ist – einer der häufigsten WooCommerce-spezifischen Beschwerdepunkte überhaupt.

Wie behebe ich WooCommerce-Barrieren technisch, ohne das Plugin zu verändern?

WooCommerce bringt einen eigenen Template-Override-Mechanismus mit: Die Original-Vorlagen liegen unter wp-content/plugins/woocommerce/templates/. Kopiert man eine einzelne Datei mit gleicher Unterordnerstruktur in einen Ordner /woocommerce/ im (Child-)Theme, sucht WooCommerce dort zuerst danach. Das ist der zentrale, update-sichere Ort, um Markup-Fehler wie fehlende Labels oder falsche Heading-Reihenfolgen gezielt zu reparieren, ohne die Plugin-Dateien selbst anzufassen.

Noch besser: Wo immer möglich, sollten Hooks und Filter in der functions.php genutzt werden statt kompletter Template-Kopien – etwa woocommerce_before_single_product, woocommerce_available_payment_gateways oder woocommerce_quantity_input_args. Ein komplett kopiertes Template friert den damaligen Stand ein und bekommt künftige Accessibility-Verbesserungen von WooCommerce nicht mehr automatisch mit, ein Hook bleibt dagegen kompatibel. Veraltete Blöcke wie den „All Products"-Block oder ältere Filter-Blocks (vor Einführung der aktuellen „Product Filters"-Blocks) sollte man im Block-Editor gegen die aktuellen „Product Filters"- und „Product Collection"-Blocks austauschen – das behebt mehrere offiziell im Accessibility Conformance Report dokumentierte Lücken ohne eigenen Code.

Welches WooCommerce-Theme ist barrierefrei?

Kein Theme ist „out of the box" vollständig konform – aber als vergleichsweise solide Ausgangsbasis gelten Storefront (das WooCommerce-eigene Standard-Theme, seit Version 1.4 gezielt bei Kontrasten und der Tastaturbedienung von Dropdown-Menüs nachgebessert), Astra, Neve und OceanWP. Alle vier brauchen dennoch manuelle Nacharbeit, insbesondere wenn zusätzlich ein Page-Builder zum Einsatz kommt.

Bei Divi fehlt standardmäßig ein Skip-Link, CSS entfernt sichtbare Fokus-Rahmen, und Dropdown-Menüs sind oft nur per Maus-Hover erreichbar. Bei Elementor sind Untermenüs im Menü-Widget häufig nicht per Tastatur (Enter) bedienbar, bei hohem Zoom oder im Hamburger-Modus teils gar nicht erreichbar. Das WordPress.org-Verzeichnis verschärft zudem gerade die Kriterien für das „Accessibility-ready"-Tag: Theme-Autoren müssen bis zum 30. Juni 2026 nachbessern oder verlieren das Label – das Tag allein war also nie ein verlässlicher Nachweis und wird es auch danach nicht automatisch sein.

Reicht ein Overlay-Widget oder Accessibility-Plugin für WooCommerce?

Nein – auch wenn im WooCommerce-Umfeld genau dafür geworben wird. Overlay-Lösungen wie accessiBe/accessWidget, UserWay oder AudioEye (das sich explizit als „WooCommerce ADA & WCAG Compliance"-Produkt vermarktet) legen eine Bedienoberfläche über den Shop, ändern aber keinen echten Code. accessiBe wurde 2025 von der FTC wegen irreführender Werbung und gefälschter Bewertungen zu 1 Mio. USD Strafe verurteilt und zu 20 Jahren Auflagen verpflichtet. UserWay wurde von einem Kleinunternehmen (BloomsyBox) verklagt, das das Widget selbst als Compliance-Maßnahme installiert hatte und dennoch verklagt wurde – der Fall ist vor einem US-Bundesgericht in Delaware weiterhin anhängig.

Selbst Elementors eigenes Accessibility-Widget „Ally" setzt einen positiven tabindex auf sein Trigger-Element, was Audit-Tools wie axe oder WAVE als WCAG-2.4.3-Verstoß gegen die korrekte Fokus-Reihenfolge melden – ausgerechnet bei einem als Barrierefreiheits-Fix verkauften Produkt. 2024 nannten rund 25 % der ADA-Digital-Klagen in den USA das Overlay-Widget selbst als Barriere. Auch Cookie-Banner-Plugins wie Real Cookie Banner, Complianz oder Borlabs Cookie werben mit WCAG-2.2-AA-Konformität, unabhängige Analysen fanden bei allen geprüften Lösungen jedoch reale Fokus-Fallen. Das muss pro eingesetztem Plugin einzeln getestet werden, nicht pauschal als erledigt angenommen werden.

WooCommerce-Barrierefreiheit: Praxis-Checkliste

Diese Punkte prüfen wir in einem WooCommerce-Audit immer zuerst – als Selbsttest lässt sich damit schon vor einem professionellen Check ein erster Eindruck gewinnen. Wer unsicher ist, wo der eigene Shop steht, kann auch unseren kostenlosen Kurzcheck nutzen; für eine vollständige Prüfung nach WCAG 2.1 AA bieten wir ein Audit für 490 € an.

Dieser Ratgeber ist allgemeine Information zum Stand Juli 2026 und ersetzt keine Rechtsberatung. Im Zweifel wenden Sie sich an eine auf IT-Recht spezialisierte Kanzlei.