EAA compliance for WooCommerce stores

If you run your store on WooCommerce and sell to EU consumers, the European Accessibility Act applies to you. WordPress and WooCommerce being open-source and endlessly customisable is exactly what makes this different from a hosted platform like Shopify: you have more control, but that control means more of the responsibility sits with you, not with the platform.

This guide covers why WooCommerce stores are in scope, the accessibility pitfalls specific to how WooCommerce and WordPress work, and what to actually do about it.

Why WooCommerce stores are in scope

The EAA has been enforceable since 28 June 2025. It covers ecommerce as a service, and it applies based on who you sell to, not what software you run. A UK-registered store selling to customers in Germany, France or Ireland is in scope, regardless of whether it's built on WooCommerce, Shopify, a custom stack, or anything else. There is no platform exemption.

WooCommerce itself takes a clearer public position on this than most platforms. Its own accessibility page states plainly that WooCommerce has adopted WCAG as its benchmark, and that the WooCommerce.com purchase flow is conformant with WCAG 2.1 Level AA, which, as the page also notes, satisfies the European standard EN 301 549, the technical standard behind the EAA.

That's a genuinely useful baseline. But, and this is the part that matters most for this guide, it's a statement about WooCommerce's own core code and purchase flow, not about your specific store. The moment you add a theme, install plugins, and start writing product content, you've introduced code and decisions WooCommerce never tested and can't be responsible for. WordPress's own accessibility documentation is consistent on this point across multiple independent reviews: WordPress core is generally accessible, but themes, plugins, and content are where accessibility barriers actually tend to appear.

Pitfall 1: theme choice, and what "accessible" themes actually deliver

WordPress has an official "accessibility-ready" tag, administered through its theme review process, that some themes carry. It's a genuine standard, themes have to meet a defined set of requirements to earn it, and WordPress's Accessibility Team has been actively updating and modernising those requirements. Choosing a theme with this tag is a better starting point than picking one at random.

But two things follow from this that are easy to miss.

First, "accessibility-ready" is a WordPress-wide theme standard, not a WooCommerce-specific one. A theme can be accessibility-ready for WordPress's general page and post templates while still handling WooCommerce's shop, product, and cart templates poorly, those are a separate layer the base accessibility-ready review doesn't necessarily dig into in the same depth. Several independent reviews of accessibility-focused WooCommerce themes specifically flag keyboard navigation as a recurring weak point, even in themes marketed as accessible.

Second, the tag describes the theme as shipped, not your configured version of it. Once you've customised colours, rearranged the homepage with a page builder, added custom CSS, or dropped in a code snippet from a tutorial or a developer who's moved on, none of that was covered by the original accessibility-ready review. What actually determines your store's accessibility is your specific configuration, not the theme's name on the WordPress.org repository.

Common things we find at theme level on WooCommerce stores: focus indicators removed or invisible against custom colour schemes, mega menus and mobile menus built with page-builder widgets that can't be operated by keyboard, product galleries and variation selectors (colour swatches, size pickers) that a screen reader can't interpret, and quantity steppers or "add to cart" buttons rebuilt with custom JavaScript that broke standard keyboard behaviour along the way.

Pitfall 2: plugins, the single biggest risk on WooCommerce

This is the WooCommerce equivalent of the app-store risk on Shopify, and if anything it's a bigger factor here, because WordPress's plugin ecosystem is larger and less centrally reviewed than Shopify's App Store.

Every plugin you install can inject its own HTML, CSS and JavaScript into your storefront, code that wasn't reviewed as part of any accessibility-ready theme process and that you often can't easily audit yourself. Independent WordPress accessibility guides are consistent on this: WordPress core provides a reasonably solid accessibility foundation, but third-party plugins are frequently where genuine barriers get introduced, precisely because there's no equivalent gatekeeping to the theme review process.

The usual culprits mirror what we see on other platforms, adapted to common WooCommerce plugin categories: popup and email-capture plugins that trap keyboard focus with no way to Tab out or press Escape; cookie consent plugins that can't be dismissed by keyboard; review and star-rating plugins with no text a screen reader can announce; live chat plugins that grab focus or sit unreachable at the end of the tab order; and product filter or "quick view" plugins that update the page without telling assistive technology anything changed.

A note on accessibility overlay plugins specifically

If your instinct is to solve WooCommerce accessibility by installing an overlay plugin, a single plugin promising to make your whole site compliant, be careful. In April 2025 the FTC issued a final order requiring accessiBe, the market-leading overlay vendor, to pay $1 million and barred it from claiming its automated products can make any website WCAG-compliant. Overlays sit on top of your existing code as a script; they don't rewrite the underlying HTML, CSS and JavaScript that actually determines whether your theme and plugins are accessible. We cover why this matters in more depth in our guide on why accessibility overlays don't make you compliant.

Pitfall 3: checkout, where WooCommerce's baseline is genuinely strong, but yours may not be

WooCommerce's own accessibility statement specifically calls out the WooCommerce.com purchase flow as WCAG 2.1 AA conformant. That's a real, useful baseline to inherit, arguably WooCommerce's clearest accessibility strength, since checkout is exactly where accessibility failures cost the most (a customer who can't complete a purchase, rather than one who's mildly inconvenienced browsing).

Where it goes wrong is customisation, and WooCommerce checkouts get customised more than most. Common patterns that break an otherwise-accessible checkout:

• Checkout field editor plugins that add, remove, or reorder fields, a very common WooCommerce customisation, can easily disconnect a field from its label in the underlying markup, even though it looks correctly labelled on screen.
• Custom payment gateway integrations beyond WooCommerce's core-supported gateways sometimes render their own payment UI, entirely outside WooCommerce's tested checkout markup, with no guarantee of the same accessibility standard.
• Upsell, cross-sell, and "complete your order" plugins that inject additional UI into the checkout flow are third-party code rendering inside what was otherwise a WCAG 2.1 AA conformant page, and none of it is covered by WooCommerce's own conformance statement.
• Page builder plugins used to visually redesign the checkout page can strip or override the semantic markup WooCommerce originally shipped with, even when the visual result looks identical.

We've found exactly this pattern of issue on other ecommerce platforms in our own audits: a checkout where the core system is properly tested and one specific payment option or add-on breaks the experience for a keyboard or screen reader user, with nothing visually wrong to suggest it. In one case, a payment method sat directly alongside a fully working one, looked completely normal, and simply could not be reached by keyboard at all, see our skincare retailer case study for the full details.

What a WooCommerce store owner should actually do

1. Establish where you stand, automatically. Run an automated scan across your homepage, a shop/category page, a product page, and your cart. Fast and free, and it catches the surface-level issues worth fixing immediately, missing alt text, contrast failures, unlabelled links. Treat the result as a starting point, not a verdict.
2. Test the purchase journey by keyboard. Unplug your mouse. Starting at your homepage, use Tab, Shift+Tab, Enter, Space and Escape only, and try to complete a real purchase: browse the shop page, open a product, choose any variations, add to cart, remove an item, go to checkout, and select each available payment method. Most WooCommerce stores find something within ten minutes, especially around any customised checkout fields.
3. Test with a screen reader. NVDA, a free screen reader commonly used for UK compliance testing, runs on Windows, and VoiceOver is built into macOS. Check whether your navigation makes sense, whether product images are described usefully, and, specifically for WooCommerce, whether any checkout field editor or custom payment plugin has broken the labelling on your payment and shipping forms.
4. Audit your installed plugins deliberately. List every plugin that renders something on your storefront, particularly around checkout. For each one, check whether you can reach and dismiss it by keyboard, and whether it's actually still needed. Every plugin is added risk and added code you didn't write.
5. Check your theme's WooCommerce templates specifically, not just its general pages. An "accessibility-ready" tag covers WordPress's general theme requirements; it doesn't guarantee your shop, product, and cart templates were reviewed to the same standard. Test them directly rather than assuming the tag covers everything.
6. Fix the code, not the symptoms. Contrast and alt text are usually fixable through the WordPress admin and theme customiser. Focus management, keyboard traps, and checkout field labelling issues usually need actual theme or plugin code changes. Either way, the fix needs to go into your source code, that's what actually removes the barrier.
7. Retest after every change. Theme updates, new plugins, checkout customisations, a redesign, a new product range, each can reintroduce issues you already fixed. This is especially true on WooCommerce given how often plugin updates happen outside your direct control. Fix it, document it, then check it stays fixed.
8. Publish an accessibility statement. State the standard you're working to, what you've done, what's outstanding, and how someone can report a problem. This is part of what's expected of you under the EAA, and it's a stronger, more honest position than silence or an overstated claim.

Not sure where to start?

If you want a fast starting point, our free scanner checks any URL and emails you the results.

See what's included in our audits, from £350

Frequently asked questions

Does using WooCommerce make my store more or less accessible than a hosted platform like Shopify?

Neither, inherently, it's a different risk profile, not a better or worse one. WooCommerce's own core purchase flow is a genuinely tested WCAG 2.1 AA baseline, which is a real strength. But WordPress's open plugin ecosystem is larger and less centrally reviewed than a hosted platform's app store, so the risk shifts more heavily onto your specific theme and plugin choices.

Is an "accessibility-ready" WordPress theme enough on its own?

It's a good starting point but not a guarantee. The tag covers WordPress's general theme review requirements; it doesn't specifically guarantee your WooCommerce shop, product, and cart templates were tested to the same depth, and any customisation you make afterward falls outside the original review entirely.

Should I use an accessibility overlay plugin instead of testing manually?

We'd caution against relying on one. Overlays operate as a layer on top of your existing code rather than fixing the underlying HTML, CSS and JavaScript, and the market-leading overlay vendor was fined $1 million by the FTC in April 2025 for overstating what its product could actually achieve. See our full guide on why overlays don't make you compliant for the detail.

What's the single most common accessibility issue you find on WooCommerce checkouts specifically?

Based on the pattern we consistently see across ecommerce platforms generally, it's usually a specific customisation, a checkout field editor, a custom payment gateway, or an upsell plugin, that quietly breaks keyboard or screen reader access to one part of an otherwise solid checkout, without any visual sign that anything is wrong.