WooCommerce powers a huge number of online stores, and most of them share the same accessibility problems: an inaccessible product gallery, variation selectors that ignore the keyboard, and a checkout that traps or confuses anyone who cannot use a mouse. The encouraging part is that WooCommerce accessibility comes down to a short list of high-traffic components, and fixing those covers most of what WCAG 2.2 Level AA and the European Accessibility Act actually check for.
This guide is written for store owners, not just developers. It walks through the theme, product galleries, variable-product selectors, and the cart and checkout, then explains what the EAA means if you sell to EU customers. For a fast baseline, you can run a free scan with AccessScan before you start fixing anything.
What WooCommerce accessibility actually requires
The baseline is WCAG 2.2 Level A and AA. In the EU, the European Accessibility Act (Directive (EU) 2019/882) has required this of in-scope products and services since 28 June 2025, referenced through the harmonised standard EN 301 549. Because a WooCommerce store sells to consumers, it is exactly the kind of service the EAA targets.
WCAG 2.2 added several criteria that hit online stores directly: 2.5.8 Target Size (Minimum) wants interactive targets to be at least 24 by 24 CSS pixels, which catches tiny quantity steppers and swatches; 2.4.11 Focus Not Obscured (Minimum) stops a sticky add-to-cart bar from hiding the focused element; 3.3.7 Redundant Entry means a buyer should not have to retype their address at checkout; and 3.3.8 Accessible Authentication (Minimum) means do not force a cognitive puzzle to log in. Contrast still matters too: 4.5:1 for normal text, 3:1 for large text (at least 18pt, or 14pt bold) and for UI components like form borders and buttons. You can verify colours with the contrast checker.
Start with the theme
Most WooCommerce accessibility problems are inherited from the theme, so this is where the biggest wins are. Storefront and the default block themes are a reasonable starting point because they ship sensible heading order, visible focus styles, and a skip link. Heavily designed marketplace themes are where things break: missing focus indicators, decorative icon buttons with no accessible name, and colour palettes that fail contrast on sale badges and 'Add to cart' buttons.
Page builders deserve special attention. Elementor and similar tools make it easy to drop in sliders, accordions, and icon boxes that look fine but expose no semantics to assistive technology. If you build product or category templates this way, treat the output as suspect and test it. See the broader WordPress accessibility guide for theme and builder specifics that apply to the WooCommerce layer too.
- Tab through a product page with no mouse: every link, button, swatch, and the quantity field must be reachable and show a visible focus ring.
- Check that 'Add to cart', 'Apply coupon', and 'Place order' are real <button> elements, not <div> or <a> with a click handler.
- Confirm one <h1> per page and a logical heading order, since screen reader users navigate category and product pages by headings.
Fix the product gallery and zoom
The WooCommerce product gallery is a frequent failure point. By default it uses a thumbnail slider plus a zoom and lightbox (PhotoSwipe). The lightbox often opens with no keyboard way out, no focus management, and no announcement, which is a keyboard trap under WCAG 2.1.2. Test it: open zoom with the keyboard, confirm focus moves into the overlay, that Escape closes it, and that focus returns to the trigger image.
Every product image needs meaningful alt text describing the product, not the filename, and gallery thumbnails that only switch the main image should not repeat the same alt over and over. Our alt text guide covers the wording. If the gallery is a carousel, make sure it is not auto-rotating without a pause control, and that the thumbnail strip is operable with arrow keys rather than mouse drag alone, which also relates to WCAG 2.5.7 Dragging Movements.
Make variable-product selectors keyboard-operable
Variable products are where WooCommerce stores most often lock people out. Native WooCommerce renders variations as a <select> dropdown with a 'Choose an option' label, which is accessible by default. The trouble starts with swatch and visual-selector plugins that replace those selects with styled <div> or <span> elements carrying no role, no keyboard handling, and no announced selected state.
A correct swatch is a group of real radio inputs or buttons with aria-pressed, each with an accessible name like 'Colour: Navy', operable with Tab and arrow keys, and kept in sync with the underlying select so add-to-cart still works. The selected option must be conveyed by more than colour alone (WCAG 1.4.1), so add a checkmark, border, or text label. When a combination is out of stock, announce that, do not just grey it out silently. For the deeper patterns here, see accessible forms and keyboard accessibility.
Cart and checkout: where conversions are won or lost
WooCommerce now offers Cart and Checkout blocks alongside the classic shortcode versions. The blocks are generally more accessible and are the better default for new stores, but neither is automatically compliant once you add custom fields and plugins. The recurring issues are the same across both.
- Form fields need persistent <label> elements, not placeholder-only labelling, and required fields must be marked in text, not by colour or an asterisk alone.
- When validation fails, move focus to an error summary and tie each message to its field with aria-describedby, so screen reader users know what to fix and where.
- AJAX 'Add to cart' and cart-total updates must be announced via an ARIA live region, or the change is silent to screen reader users. WooCommerce ships a live region, but custom mini-carts often bypass it.
- The quantity stepper buttons and the 'remove item' control must meet the 24 by 24 px target size and have accessible names.
- Honour Redundant Entry: prefill or let buyers reuse the shipping address for billing instead of retyping it.
Test the entire path with a keyboard and a screen reader, from product page to order confirmation, including a deliberately failed payment. A checkout that cannot be completed without a mouse is both a lost sale and a clear WCAG failure. For a structured pass, work through the accessibility checklist.
EAA implications for EU sellers
If you sell goods or services to consumers in the EU, your WooCommerce store is most likely in scope of the EAA, with requirements in force since 28 June 2025. In practice that means meeting WCAG 2.2 Level A and AA across the journey customers actually use: browsing, product pages, cart, checkout, and account. A limited exemption exists for some genuine microenterprises providing services, but do not assume it applies to you without checking the rules for your situation. For the wider e-commerce picture, see the EAA compliance guide for ecommerce.
Compliance is also something you should document. Many stores publish an accessibility statement describing their conformance status and how to report problems; you can produce one with the free accessibility statement generator. Treat it as a living document that reflects real testing, not a badge you paste on once.
What to fix first
You do not need to do everything at once. Prioritise the components every buyer touches, in this order:
- Checkout: labels, keyboard operability, error handling, and announced cart updates, because this is where revenue and legal risk concentrate.
- Variable-product selectors: make swatches keyboard-operable with announced state, or revert to the native accessible <select>.
- Product gallery: fix the lightbox keyboard trap and add real alt text.
- Theme-wide basics: visible focus, contrast on buttons and badges, and correct heading order.
Run an automated scan to catch the obvious markup and contrast issues, then verify the interactive flows by hand, since galleries, swatches, and checkout logic need human testing. Start with a free pass from AccessScan and fix top to bottom.