WooCommerce accessibility and the EAA

Where WooCommerce stores usually fail

Checkout is the single most common failure point we see: payment-gateway plugins frequently render their own card-entry fields inside an iframe or a custom widget that doesn't associate labels with inputs correctly, which breaks screen-reader users' ability to know what field they're filling in. Product-variation selectors (size/color swatches built as styled <div> or <span> elements instead of real form controls) are another recurring one — visually they work with a mouse, but they're invisible to keyboard-only and screen-reader navigation. And like any WordPress site, an inaccessible theme is often the root cause underneath everything else: missing skip links, heading levels that jump from an <h1> straight to an <h4>, and low-contrast "sale" badges are all theme-level, not WooCommerce-level, issues.

Plugins don't stack for free

A common assumption is that installing an "accessibility plugin" fixes a WooCommerce store wholesale. In practice, an overlay-style plugin injects a widget on top of the page without changing the underlying markup — it can't fix a checkout field that has no programmatic label, because that requires editing the actual HTML/PHP the theme or gateway plugin generates. There's more on why overlay tools specifically fall short of what the EAA requires on our overlays page.

Does the EAA apply to a WooCommerce store?

The same rule applies regardless of platform: if you sell to EU consumers and aren't a qualifying micro-enterprise, the EAA's accessibility requirements apply to your storefront. WooCommerce being open-source and self-hosted doesn't change that — the obligation follows the merchant, not the software.

Other platforms