WooCommerce is neither accessible nor inaccessible on its own. What counts is what your shop renders: theme, page builder, plugins and product data. In WooCommerce shops, most barriers sit in five places – the consent banner, variant selectors, AJAX filters and carts, menus, and a checkout with embedded payment fields. This page separates what WordPress and WooCommerce give you from what stays your job, and names the places to test first.
Does the BFSG apply to your WooCommerce shop?
If you sell to consumers through WooCommerce, you provide an e-commerce service – in the words of the law, a "Dienstleistung im elektronischen Geschäftsverkehr" (§ 1(3) no. 5 BFSG). In Germany the Barrierefreiheitsstärkungsgesetz has applied to such services since 28 June 2025. It transposes the European Accessibility Act, so shops selling into other EU countries meet equivalent national laws there [1][2].
Micro-enterprises that provide services are exempt: fewer than 10 employees and an annual turnover or balance sheet total of no more than €2 million (§ 2 no. 17, § 3(3) BFSG) [1]. Both conditions must be met. How to count staff and what applies inside a group of companies is explained on our page on the micro-enterprise exemption. A purely B2B shop that only sells to business customers is not a service to consumers; if you sell to both, treat the consumer side as covered.
Scope, market surveillance and the information you have to publish are explained in BFSG for online shops. Most of this page applies to any WordPress site as well – the WordPress-wide view is in WordPress accessibility and the BFSG.
What the platform gives you, and what it does not
You get:
- Cart and Checkout blocks. Since WooCommerce 8.3, the block-based cart, checkout and order confirmation are the default for new installations [3]. They use native form controls with visible labels. Shops that were set up earlier keep the classic shortcode checkout until somebody switches.
- A core held to WCAG 2.2 AA. Under the WordPress Accessibility Coding Standards, code in WordPress core, on WordPress.org and in official plugins is expected to conform to WCAG 2.2 at level AA [4].
- "accessibility-ready" themes. Themes with this tag in the WordPress.org directory pass a manual review by the accessibility team against a list of requirements, among them a skip link, keyboard navigation, headings with a meaningful structure, labelled form fields and sufficient contrast [5].
- A native variant selector. Without an add-on, WooCommerce renders variations as a
<select>. It works with a keyboard, and screen readers announce it properly.
You do not get:
- A guarantee for your theme. "accessibility-ready" covers the reviewed theme as shipped. It does not cover your child theme, your colours or your customisations, and themes sold on marketplaces outside WordPress.org are not reviewed at all.
- Control over page-builder output. What Elementor, Divi or WPBakery render depends on the widget you choose and how you configure it.
- Accessible plugins. Every plugin with front-end output brings its own markup and JavaScript. The plugin directory does not review them for accessibility.
- Useful alt text. Alt text comes from your media library or your product import. When it is missing, many themes fall back to the file name or the product name, and neither describes the image.
What we find on WooCommerce shops
Consent banners in front of everything
The consent tool is the first thing on every page, so one defect there affects the whole shop. Typical problems: focus does not move into the dialog, you can tab behind it, "Reject" is a low-contrast text link, or the icon that reopens the settings has no accessible name. Whether this happens with Borlabs Cookie, Real Cookie Banner, Complianz or another tool depends heavily on version, layout choice and custom CSS – test the configuration you ship, not the vendor's demo.
Variant swatches
Swatch plugins replace the native select with colour or image tiles. Often these are div or span elements that cannot take focus and have no name. The selected state shows only as a border, "sold out" only as a strikethrough. When price or availability then changes, a screen reader hears nothing.
Silent carts, mini-carts and filters
AJAX "Add to basket" is convenient, but for many users nothing happens: there is no status message, and the off-canvas mini-cart opens without moving focus into it. AJAX filters reload the product grid without announcing the number of results, and focus often ends up at the top of the page. Price range sliders frequently work only by dragging.
Page-builder mega menus
Submenus open only on hover. The trigger is a link rather than a button and has no aria-expanded. In the mobile off-canvas menu, keyboard focus stays behind the open panel, so a keyboard user tabs through links they cannot see.
Sliders and product galleries
Hero sliders autoplay with no pause control. Arrows and dots are icons with no labels. In gallery lightboxes, Escape sometimes does not close the lightbox, or focus is lost once it closes.
Checkout with payment iframes and mandatory checkboxes
Payment providers embed card fields and express buttons as iframes. If those iframes have no title, or the focus order breaks on the way out of them, the purchase fails right there. In the classic shortcode checkout, errors may be listed at the top instead of beside the field, depending on version and theme. Checkout field editors often strip autocomplete attributes. Mandatory checkboxes from German legal-text plugins such as Germanized or German Market need a properly associated label and a clear error message.
Where to look first
| Criterion | Why on WooCommerce | Automation |
|---|---|---|
| 2.1.1 Keyboard (A) | Swatches, mega menus, price sliders | Partly automated |
| 2.1.2 No Keyboard Trap (A) | Consent dialog, lightbox, payment iframe | Partly automated |
| 2.4.3 Focus Order (A) | Mini-cart, off-canvas menu, filters | Partly automated |
| 2.4.7 Focus Visible (AA) | Theme CSS with outline: none | Partly automated |
| 4.1.2 Name, Role, Value (A) | Swatches, icon buttons, menu toggles | Partly automated |
| 4.1.3 Status Messages (AA) | AJAX cart, filter results | Manual only |
| 3.3.1 Error Identification (A) | Checkout errors, mandatory checkboxes | Manual only |
| 1.3.5 Identify Input Purpose (AA) | Customised checkout fields | Partly automated |
| 1.1.1 Non-text Content (A) | Imported product images | Partly automated |
| 1.4.3 Contrast (Minimum) (AA) | "Reject" links, price badges | Automated |
"Automated" means a rule can decide the criterion on its own; "partly automated" means a rule finds some failures and a person has to judge the rest. The full list is in WCAG 2.2 AA, criterion by criterion.
A sensible order of work
- Isolate theme and builder. Scan a staging copy once with a default theme (Storefront or a current Twenty Twenty-something theme). Whatever disappears came from your theme or builder.
- Fix the consent banner first. It is on every page, so one fix clears a finding on every URL.
- Walk the purchase journey with a keyboard. Home → category → filter → product → variant → basket → checkout → payment in test mode. The homepage alone tells you little.
- Inventory your plugins. List every plugin with front-end output and decide for each one: patch it, replace it, or document it as a known limitation. Ask vendors for test evidence rather than a badge.
- Fix alt text at the source. Do it in the media library or in your import (CSV, WP All Import, ERP), not page by page.
- Re-test after every update. Payment, filter and consent plugins update often. A scheduled crawl catches regressions before customers report them.
What Reviseberg checks on WooCommerce – and what you still test yourself
Reviseberg crawls your shop, including category and product pages, and runs every axe-core rule on every page at a desktop width of 1280 pixels, then repeats the rules that change with the layout – contrast and target size among them – at 360 pixels. Results are mapped to WCAG 2.2 A/AA and EN 301 549. Findings are grouped into issues by rule and ranked by the points you gain by fixing them, so a theme defect shows up as one issue on 400 pages rather than 400 separate entries.
The keyboard agent opens the pages of a journey you name – a category page, a product page, the basket – and presses Tab, Shift+Tab and Escape through each of them, recording every step. It reports unreachable elements, lost or invisible focus, missing skip links and keyboard traps. It does not fill in forms or place an order, so the checkout steps behind a full basket and the payment iframe are yours to walk by hand. The free report covers up to 100 pages and runs the keyboard agent on one page you choose.
You still test some things yourself: whether alt text actually describes the image, whether error messages make sense, and how the shop behaves with a screen reader and zoom. Screen-reader, zoom and voice-control agents are not built yet; for those criteria the platform gives you guided manual tests, and a criterion nobody has tested is reported as untested, never as passed. Nothing is applied to your shop automatically, and we never inject an overlay script.
Written to be useful, not as legal advice. As of 27 September 2026.