WooCommerce itself is a reasonable starting point. Its default templates include labels, its notices use proper markup in many places, and the team behind it has put work into the newer block-based cart and checkout. Live stores still tend to show the same handful of problems once you test them with a keyboard.
The reason is that almost no store runs plain WooCommerce. There is a theme on top, a swatch plugin, a mini cart plugin, a quick view feature, a page builder, a payment gateway or three. Most WooCommerce accessibility issues come from those layers, and from the places where they meet. This post lists the ones we see most, how to spot each one in a few minutes, and what the fix usually involves.
How to spot WooCommerce accessibility issues quickly
You do not need special software for a first look. Open a product with options on a laptop and leave the trackpad alone: move with the Tab key (Shift+Tab goes back), and press Enter, Space or the arrows to operate things. After that, repeat the same steps with a free screen reader running, NVDA if you use Windows or the VoiceOver that ships with every Mac, and listen.
You are listening for three things: can I reach it, can I tell what it is, and do I know what happened after I used it. Most of the issues below fail one of those three.
Variation dropdowns and swatch plugins
A variable product in WooCommerce uses ordinary dropdown menus by default for size, color and so on. Native dropdowns are usually fine with a keyboard and screen reader. The trouble starts when a swatch plugin hides the dropdown and replaces it with colored circles or text boxes.
Signs of trouble:
- Tab skips the swatches entirely, because they are plain
divorspanelements with a click handler. - The screen reader reaches them but says only “clickable” or nothing useful.
- The selected swatch is shown only by a border color, so nobody using a screen reader knows which one is chosen.
- Unavailable combinations are shown with a faint cross that has no text equivalent.
The fix is to make each swatch a real button or radio input with a name (“Navy”, “Large”), expose the selected state, and announce when a combination is out of stock. Some swatch plugins do this well and some do not. Testing two or three on a staging copy is often quicker than patching a poor one.
Also check what happens after a choice. When a variation changes the price, the photo and the stock message, a sighted shopper sees it at once. A screen reader user hears nothing unless that area is set up to announce updates.
Quantity fields and plus/minus buttons
The default WooCommerce quantity box has a label that is hidden visually but available to screen readers. Themes and “quantity buttons” plugins often override that template and drop the label, or add plus and minus buttons that are icons with no name. The result is a screen reader saying “spin button, 1” next to two unnamed buttons.
What a good one looks like in markup:
<label for="qty-123">Quantity, Linen Shirt</label>
<button type="button" aria-label="Decrease quantity">−</button>
<input id="qty-123" type="number" min="1" value="1">
<button type="button" aria-label="Increase quantity">+</button>The label can be visually hidden if your design has no room, but it has to exist. The buttons also need to be large enough to tap; WCAG 2.2 sets a minimum target of 24 by 24 CSS pixels in criterion 2.5.8, with some exceptions, and tiny plus and minus icons are a common miss.
Add to cart feedback and store notices
WooCommerce shows messages such as “Linen Shirt has been added to your cart” or “Please choose product options”. On many themes these appear at the top of the page, styled as a colored box. Two things go wrong.
First, on archive pages that use AJAX add to cart, the button changes or a small “View cart” link appears, and nothing is announced. A screen reader user cannot tell if the click worked. Second, on single product pages the notice can appear far above the button that caused it, and focus stays where it was, so the message is never heard.
The usual fix combines two things: the message area is a live region that announces new text (criterion 4.1.3 Status Messages covers this), and for errors focus is moved to the notice or to the field that needs attention. Watch for notices that disappear on a timer too; someone reading slowly or zoomed in may miss them.
The mini cart drawer
Many themes open a slide-out cart after an item is added. It is one of the most common WooCommerce barriers, because the drawer is effectively a modal dialog but is rarely built like one.
Press Tab once the drawer opens. Does focus go into the drawer, or does it keep moving through the page hidden behind it? Can you close it with Escape? When it closes, does focus return to where you were? Is each “remove item” control named with the product it removes?
If the drawer fails these, either the theme needs fixing, or it is simpler to turn the drawer off and send people to the cart page, which uses a standard table. That is a fair trade on a small store.
Block cart and checkout vs the classic shortcode
Newer WooCommerce installs use the Cart and Checkout blocks; older stores often still use the classic shortcode pages. They behave differently, and that matters for accessibility testing.
| Area | Classic shortcode checkout | Block checkout |
|---|---|---|
| Markup | PHP templates your theme can override | Built by the blocks themselves; themes style it but rarely restructure it |
| Errors | Usually a notice list at the top after submit | Usually shown next to the field |
| Plugin fields | Most older checkout plugins hook in here | Some older plugins do not add their fields at all |
| Where problems come from | Theme overrides and old plugins | Custom styling, extensions and payment fields |
Neither one is accessible or inaccessible by default. Test whichever one you have, as it actually appears on your site. If you are thinking of switching, test the block version on a staging copy with your real plugins first. Our post on how to update WooCommerce safely covers staging and backups. The field-by-field checks for either version are in our accessible checkout guide.
Sorting, filters and pagination on the shop page
The default “Sort by” menu on shop pages reloads the page as soon as its value changes. In some browsers, moving through the options with the arrow keys counts as a change, so a keyboard user gets sent to a new page before they reach the option they wanted. A small “Sort” button, or a script that waits for Enter, fixes it.
Filter plugins add a bigger set of issues, such as result counts that are never announced and price sliders that ignore the keyboard. Those have their own post on product filter accessibility.
Galleries, quick view and the review form
- Product gallery and lightbox. Check that thumbnails are reachable, that the zoomed view has a close button with a name, and that Escape closes it.
- Quick view popups. Same rules as the mini cart: focus in, focus trapped while open, Escape to close, focus back to the trigger.
- Star rating in the review form. The rating picker is usually a row of stars. Make sure each one is reachable and announces “4 of 5 stars”, and that the chosen rating is clear.
- Sale badges and stock labels. Check contrast; a white “Sale” on light pink is common and fails the 4.5:1 ratio for normal text.
Order of work for a WooCommerce store
Once you have a list of WooCommerce accessibility issues, work through them in an order that protects orders first:
- Copy the site to staging so tests and fixes do not touch real orders.
- Run one complete purchase with the keyboard, then with a screen reader, and note every problem.
- Fix checkout, cart and mini cart first.
- Fix the product template: variations, quantity, add to cart feedback, gallery.
- Fix the shop and category templates: sorting, filters, pagination, product cards.
- Replace plugins that cannot be fixed with ones that behave properly.
- Retest after every WooCommerce, theme or payment plugin update, yourself or through ongoing accessibility monitoring.
If you want the bigger picture of the whole shopping journey, not just the WooCommerce parts, start with our guide to the accessible online store. For general store help beyond accessibility, there is our WooCommerce support page.
Frequently asked questions
Will a WooCommerce update undo these fixes?
It can. Changes made directly in WooCommerce or theme files are overwritten by updates, so fixes belong in a child theme or a small site plugin. Template overrides in a child theme can also fall out of date when WooCommerce changes its templates, and the WooCommerce status screen lists outdated ones. Retest the product page and checkout after each major update.
Should I switch to the block checkout for accessibility?
Not automatically. The block checkout shows errors next to fields and has had accessibility work, but some plugins do not support it and custom styling can still cause problems. Test it on a staging copy with your real payment methods and plugins, compare it with your current checkout, and switch only if it works better for you.
Do I have to replace my swatch plugin?
Only if it cannot be made to work with a keyboard and screen reader. Test whether each swatch is reachable with Tab, has a name such as a color or size, and shows which one is selected. If not, check whether the plugin has an update or setting that helps; if it does not, a different plugin is often the quicker fix.
Can an accessibility checker plugin find these WooCommerce issues?
Some of them. A checker can find missing labels, unnamed buttons and low contrast. It cannot tell whether a mini cart traps focus, whether an add to cart message is announced or whether a swatch selection makes sense to a listener. Those need a person testing with a keyboard and screen reader.
We test and fix WooCommerce stores against WCAG 2.2 AA, working on staging and writing down what changed. Our WooCommerce accessibility fixes page explains the process, and if your site is not a store, the wider ADA website accessibility help we offer starts from the same kind of testing.
Next in this series: Accessible Checkout: A Field-by-Field Guide for Stores
