A store can look finished and still leave a screen reader user unable to select a variation or understand a checkout error. Those problems appear in the interaction, not the screenshot. Test the same path a buyer takes: product, cart, checkout, and confirmation.
Review method, September 28, 2026: This is a test procedure based on W3C WCAG 2.2 and WooCommerce’s accessibility guidance. We did not verify the first-person client audit or the claimed sample of twelve stores previously described here, so those claims have been removed. The WebAIM Million study measures detectable errors on a sample of homepages; it does not measure the share of WooCommerce stores that fail checkout.
Pick a setup and record it
On Windows, use NVDA with a current browser. On macOS or iPhone, use VoiceOver. Record the browser, screen reader, WooCommerce version, theme, payment gateway, and date. If you change one of those later, rerun the test rather than assuming the old result still applies.
You can start with a short run, but a time limit is not a pass criterion. Complete the purchase journey on a staging store or stop before final payment on a live store.
Follow the buyer’s path
- Find a product. Navigate the main menu, search, filters, and product cards. Do headings and links tell you where they lead?
- Choose options. On a variable product, change size or color. Listen for the option name, available values, selected state, and any price or stock update.
- Add to cart. Is the action clearly named? Does the store confirm it worked in a way you can perceive?
- Edit the cart. Change quantity, remove an item, and check the updated total.
- Check out. Move through every field and payment method. Submit with a required field blank. Find the error, correct it, and continue.
- Confirm the order. Check that the result and next steps are understandable without looking at the screen.
Use the keyboard as you go. A screen reader and keyboard reveal different failures: an unnamed control might be reachable, while a scripted widget might have a good name but never receive focus.
What to record when something fails
| Symptom | Where to look |
|---|---|
| A control is announced only as “button” | Its rendered accessible name and whether a native button could replace custom markup |
| A variation cannot be selected | The theme or swatch extension’s keyboard handling, role, name, and state |
| The cart total changes silently | How the update is announced and whether a live region is appropriate |
| Checkout says only “invalid input” | The field label, error text, and programmatic association |
| Focus disappears in a popup | Entry, movement, close control, and return focus |
WooCommerce says core includes accessibility features, but themes and extensions can override them. Diagnose the rendered control and fix the component producing the barrier. Retest the original steps after each change.
AmazingPlugins publishes the free AP Accessibility Fixer for WooCommerce. Its public 1.5.1 release has nine targeted fixers, including an empty product-image alt fallback, selected focus styles, and a skip link. It does not conduct this full purchase test or repair every swatch, cart update, or checkout field.
For screen reader shortcuts and a longer walkthrough, use the WooCommerce screen reader testing guide. For payment-specific checks, use the checkout accessibility guide.