A WooCommerce store falls squarely within the scope of the European Accessibility Act since June 2025. Yet between a badly coded theme, chatty plugins and a neglected checkout, WordPress accessibility is won in the details. Here are the things that actually block users, and how to fix them.
WordPress isn't accessible by default
The WordPress core makes serious accessibility efforts, but your site mostly depends on your theme and your extensions. A flashy premium theme can be a disaster on the keyboard, and every plugin injects its own HTML, often with no regard for screen readers. Compliance isn't declared, it's verified component by component.
For a store, the stakes are twofold: it's a legal obligation, and every accessibility barrier is a lost sale. A user who can't complete checkout doesn't come back.
Takeaway: a WooCommerce store is an e-commerce service, so it's directly covered by the European Accessibility Act. The risk isn't theoretical: a formal notice on one side, an abandoned cart on the other.
Start from a solid base: the theme
The first lever is the theme. WordPress.org flags audited themes with an accessibility-ready tag: keyboard navigation, contrast, visible focus and labeled forms are all checked. It's not an absolute guarantee, but it's a far better starting point than a marketplace theme sold on its animations.
Whatever the theme, three baseline checks belong in the templates:
- a correct heading hierarchy (one
h1per page, no skipped level); - a skip link to the main content;
- a visible focus that's never removed.
<?php // header.php: skip link, first focusable element ?>
<a class="skip-link screen-reader-text" href="#main">Skip to content</a>
The screen-reader-text class ships with WordPress: it hides the element visually while keeping it accessible, and reveals it on keyboard focus.
The 5 things that block users in WooCommerce
1. AJAX add-to-cart, completely silent
This is the classic trap. The customer clicks "Add to cart", a message appears, the counter updates, but nothing is announced to the screen reader. You have to push the information into an aria-live region.
<!-- Place once in the template -->
<div id="a11y-cart-status" aria-live="polite" class="screen-reader-text"></div>
// WooCommerce fires this jQuery event after the AJAX add
jQuery(document.body).on('added_to_cart', function () {
document.getElementById('a11y-cart-status').textContent =
'Product added to cart';
});
2. Stock status signalled by color alone
"In stock" in green, "Out of stock" in red: for a colorblind person, they look the same. Color information must always be paired with text or an explicit icon. WooCommerce already shows a text label; the trap comes from themes that hide it behind a colored dot.
3. Product variations without labels
Variation selectors (size, color) must be tied to a <label>. When a theme replaces the native <select> with a custom swatch widget, it often breaks that association.
<label for="size">Size</label>
<select id="size" name="attribute_size">
<option value="">Choose a size</option>
<option value="m">M</option>
<option value="l">L</option>
</select>
4. The checkout, poorly labeled
Checkout is the most critical place. Every field needs a linked label, the right autocomplete, and errors tied to the relevant field.
<label for="billing_email">Email</label>
<input id="billing_email" type="email" name="billing_email"
autocomplete="email" required
aria-describedby="billing_email_error">
<span id="billing_email_error" role="alert"></span>
The autocomplete attribute isn't just convenience: it also helps people with cognitive or motor impairments fill the form without retyping everything.
5. The product gallery on the keyboard
The image gallery and its lightbox must be usable without a mouse: keyboard navigation, close on Escape, focus trapped inside the open lightbox. Many WooCommerce galleries fail here. If yours isn't accessible, disable the zoom/lightbox effect rather than leaving a trap.
Beware "accessibility widget" plugins
Extensions that promise one-click compliance through a floating toolbar (change contrast, enlarge text) do not make your site compliant. They sit on top of the real problem without fixing it, and can even interfere with the screen readers your visitors already use. The only reliable path is fixing the HTML at the source.
| Approach | Real compliance | Risk |
|---|---|---|
| "All-in-one" overlay widget | No | Interferes with assistive tech |
| Fixing the theme and templates | Yes | none |
| Manual audit + testing | Yes | none |
How to test your store
- Full purchase journey on the keyboard: from product page to payment, no mouse.
- Screen reader on the checkout (VoiceOver, NVDA).
- axe DevTools or Lighthouse on the key pages (home, category, product, cart, checkout).
- Contrast of buttons, sale badges and stock labels.
The WooCommerce accessibility checklist
- Accessibility-ready theme, visible focus preserved
- Skip link and correct heading hierarchy
- AJAX add-to-cart announced via
aria-live - Stock status never signalled by color alone
- Product variations tied to a
<label> - Labeled checkout fields,
autocompleteand linked errors - Gallery and lightbox usable on the keyboard
- No overlay plugin used as a compliance shortcut
- Purchase journey tested on keyboard and screen reader
Going further
For the general principles (WCAG, RGAA, testing method), see: Web accessibility, the developer's practical guide. And on store performance: WooCommerce performance optimization.
Does your WooCommerce store need to become accessibility-compliant? Let's talk.