WooCommerce and the European Accessibility Act

Four layers, one legal obligation

What a customer sees is WordPress core, plus your theme, plus the WooCommerce plugin, plus whatever extensions you have installed, plus the content you typed in. Each layer is maintained by different people to a different standard. The EAA does not care about the split: the obligation attaches to the service you offer, which is all five at once.

This matters because the accessibility claims published for WooCommerce are claims about one layer, and they come with conditions that are easy to miss.

What WooCommerce actually claims

WooCommerce publishes an accessibility conformance report and describes the plugin's front end as substantially conformant with WCAG 2.2 level AA, with the admin side described as built with accessibility in mind rather than formally conformant. The announcement for version 10.0, released in July 2025, went further: WooCommerce 10.0,when used with a core WordPress or accessibility-ready theme, would be fully conformant with WCAG 2.2 level AA and substantially conformant with level AAA.

Read the condition in that sentence. The conformance claim is scoped to a theme that is either a WordPress core theme or carries the accessibility-ready tag. On any other theme, which is most commercial themes, the claim does not apply as written.

There is a second catch, and WordPress states it plainly. The theme review team's own documentation says that "Accessibility Ready" does not mean that the theme meets the WCAG guidelines AA-level. It means a reviewer checked the theme against the minimum standards the team set. So the condition attached to WooCommerce's conformance claim points at a tag that is itself explicitly not a WCAG AA guarantee.

Sources: WooCommerce accessibility,WooCommerce 10.0: investing in accessibility,Make WordPress Themes — accessibility.

Blocks or shortcodes decides which code you are running

WooCommerce has two cart and checkout implementations. The Cart and Checkout blocks have been the default for stores created since version 8.3 in November 2023. Stores older than that keep the classic shortcode-based pages until someone migrates them on purpose, and plenty never have, usually because an extension was incompatible at the time.

The accessibility work WooCommerce announced in version 10.0 is described in terms of the cart, product gallery and checkout blocks. A store still running the classic shortcodes is not running the code those improvements landed in. Checking which one you use takes a minute: open the Cart page in the editor and look for a Cart block or a[woocommerce_cart] shortcode.

Where WooCommerce stores fail in practice

Your product content

Alt text lives in the WordPress media library, attached to the image, not to the theme. Products imported from a supplier feed or a CSV arrive with that field empty, and a correctly built theme will then output thousands of empty alt attributes. Link text is the same class of problem: a grid where every product links through the words "Read more" gives a screen reader user a list of identical links with no way to tell the products apart.

Extensions

Product filters, variation swatches, wishlists, quick views, review widgets, cookie banners and popup builders add markup to pages that were fine without them. There is no accessibility gate on the WordPress plugin directory, and none on most commercial extension marketplaces. The practical test is to disable extensions one at a time when a finding matches nothing in your theme.

The theme

Page builders deserve their own mention. A layout assembled visually tends to produce headings chosen for size rather than structure, so a page ends up with three h3s and no h1, or with heading levels that jump. Screen reader users navigate by heading, and a broken outline turns the page into a wall.

Colours you chose

Theme customiser palettes apply site-wide with no contrast warning. Sale badges, stock status and form validation drawn only in red or green fail on colour alone, independently of contrast.

What to do, in order

1. Check your WooCommerce version. If you are behind 10.0, upgrading is the cheapest accessibility work available, because someone else already did it.
2. Find out whether you run blocks or shortcodes on cart and checkout, and plan a migration if you are on the classic pages and your extensions now support the blocks.
3. Scan the home page, one product page and the cart. Theme-level issues repeat everywhere, so most of what you find applies store-wide.
4. Fix alt text in the media library, at the source, rather than page by page.
5. Walk the purchase journey with the keyboard only, including the checkout validation errors. Submit the form empty on purpose and see whether the errors are announced or only coloured red.
6. Publish an accessibility statement. Thestatement generator fills in the enforcement authority and complaint route for your country.

What a scan cannot tell you

Automated testing typically catches an estimated 20–50% of real accessibility issues. On a WooCommerce store the rest is judgement: whether your alt text describes the product, whether a variation swatch announces which option is selected, whether the order of fields in checkout makes sense when you cannot see the layout, and whether an error message explains how to fix the problem. A clean scan is a floor, not a certificate.