A customer emails to say she could not finish an order. She uses a keyboard instead of a mouse, and somewhere between choosing a size and paying, the store stopped responding to her. Or a screen reader user calls your phone line because the “Add to cart” button announced nothing and he has no idea whether three jackets are now sitting in his cart. Either way, you have a WooCommerce store that takes money from sighted mouse users without trouble and quietly turns away everyone else.
This page describes our WooCommerce accessibility fixes: what we test on a store, what we change in the theme, the checkout and the plugins around it, what we cannot change (mostly the payment fields that live on a provider’s servers), and how we prove an order can be placed from start to finish without a mouse. It sits inside our accessibility work for US businesses and assumes your store runs on WordPress with WooCommerce.
Why online stores break in ways brochure sites do not
A five-page brochure site is mostly static text. A store is a machine with moving parts. Prices change when a variation is picked. The cart count updates without a page load. Coupon codes apply or fail. Shipping options appear only after a ZIP code is entered. Every one of those changes is visible to a sighted shopper and silent to a blind one unless the code tells assistive technology that something happened.
WooCommerce core, including the newer block-based cart and checkout, is built with accessibility in mind. The trouble usually comes from everything layered on top: a premium theme that restyles product cards, a swatches plugin that replaces the variation dropdown with colored circles, a mini cart drawer, a sticky “Buy now” bar, upsell popups, a reviews app, a quick-view modal. Each one may have been built with care for looks and none for keyboards.
So when we work on a store, we do not start by reading code. We start by trying to buy something.
What we test on a WooCommerce store, screen by screen
Our review follows the path a real shopper takes, and we record each barrier against the WCAG 2.2 Level AA success criterion it fails, so you and any later auditor can see why it matters. If you want the broader shopping picture first (search, emails, returns), our guide to building an accessible online store covers the full journey. Here is what a store review includes in practice.
Shop and category pages
- Product cards: does each card have one clear link, or does a keyboard user tab through the image, the title, the price and the button as four separate stops that all go to the same place?
- “Select options” and “Add to cart” buttons: does the accessible name include the product, so a screen reader list of buttons is not twenty identical entries?
- Sale badges, star ratings and stock labels: are they text, or images and icon fonts that say nothing?
- Filters, sorting and pagination: can they be reached and operated by keyboard, and is the new result count announced? Filter widgets get their own treatment in our post on accessible product filtering.
Single product pages
- The gallery: can thumbnails be reached, does the lightbox trap focus while open and return it when closed, does the zoom feature work without hovering?
- Variations: when a shopper picks “Large” and “Navy”, is the new price and stock status announced, and does a disabled combination explain itself?
- The quantity field: does it have a label, and do the plus and minus buttons have names other than “+” and “-“?
- Add-to-cart feedback: on AJAX themes the page does not reload, so we check whether a status message reaches screen readers (criterion 4.1.3 Status Messages).
- Tabs for description, reviews and size guides: are they real tabs or a row of links that do something unexpected?
Cart, mini cart and notices
We check that the cart table has proper headers, that removing an item tells you it was removed, that coupon errors are tied to the coupon field and that the mini cart drawer can be opened, used and closed with the keyboard. WooCommerce notices (the green, blue and red bars at the top of a page) are a frequent problem: they are often shown visually but not announced, or they appear far above where the shopper’s focus is, so nobody using a screen reader knows the coupon failed.
Block checkout and classic checkout need different fixes
WooCommerce stores now come in two flavors at the checkout. Newer stores usually run the Cart and Checkout blocks. Older stores, and stores whose payment or shipping plugins needed it, still use the classic shortcode checkout. Both can be made to work well, but the faults are different, and so is where the fix lives.
| Area | Classic shortcode checkout | Block-based checkout |
|---|---|---|
| Where problems usually come from | Theme template overrides, old customizations in functions.php, checkout field editor plugins | Third-party blocks and extensions that do not yet follow the block markup patterns |
| Field labels | Often fine in core, broken when a theme hides labels to show placeholders only | Floating labels are generally present; custom fields added by plugins need checking |
| Error handling | Errors gathered in a notice at the top; focus may not move to them | Inline errors near fields; we check each one is announced and linked to its field |
| Updates after address entry | Shipping and totals refresh by AJAX, often silently | Totals update in place; we confirm the change is perceivable |
| Typical fix location | Child theme templates and small code snippets | Settings, block choices, extension updates, and reports to the extension author |
We do not switch a store from one checkout to the other just because one tests better in a demo. Moving to blocks can break a payment gateway, a delivery date picker or a tax plugin. If a switch makes sense, we test it on staging with your exact plugin set first and tell you what would stop working. The finer detail of fields, autocomplete and timeouts is in our article on making the checkout step usable.
Payment plugin iframes: what we can change and what we cannot
This is where honest providers and overconfident ones part ways. Most card payment gateways show the card number, expiry and security code fields inside an iframe served from the payment company’s own servers. That is deliberate. It keeps card data off your site, which helps with security obligations. It also means nobody working on your WordPress site can edit the markup inside those fields.
What we can do:
- Fix everything around the iframe: the heading above it, the radio buttons that choose a payment method, the order of focus into and out of it, the “Place order” button and any terms checkbox.
- Check the gateway plugin’s own settings. Some offer a choice of field layout or style options that affect contrast and focus visibility.
- Try the provider’s card fields using only Tab, Shift+Tab and typing, then again with NVDA, and write down exactly what fails, with the steps, so you can send it to the provider. Providers vary in how quickly they act, but a precise report gets further than a vague complaint.
- Where a gateway’s fields are truly unusable, tell you so plainly and suggest testing an alternative gateway or a hosted payment page, with the trade-offs for your business.
What we cannot do is promise that a third party’s payment form meets WCAG. We will document it as a known third-party limitation in your report rather than pretend it is solved.
My Account, login and the screens after the sale
Stores often get tested up to the “Thank you” page and no further. Returning customers then hit a login form with an unlabeled password field, an orders table that reads as a jumble, address forms that differ from the checkout’s and a “Lost your password” flow that drops focus at the top of the page. We cover:
- Login and registration, including password visibility toggles and any CAPTCHA a security plugin has added (criterion 3.3.8 Accessible Authentication (Minimum) applies here).
- The orders list and single order view, which should be a real table with headers.
- Address and account detail forms, where we check that information you already gave is not demanded again without reason (3.3.7 Redundant Entry).
- Order confirmation and status emails, which many customers read with a screen reader in their mail app. We look at headings, link text and the order table in the default WooCommerce templates and any customizer you use.
- Subscription or membership screens if your store uses them, since pausing or cancelling is exactly where people get stuck.
How a store project runs from first test order to sign-off
Every store is different, but our WooCommerce accessibility fixes always follow the same order, because it saves you rework.
- Scoping call and access. You tell us which products are typical (simple, variable, bundles, subscriptions) and which plugins touch the cart and checkout. We take admin access and, ideally, a staging copy.
- Journey test. We buy representative products on staging using a keyboard only, then with the free NVDA screen reader and with Apple VoiceOver on desktop and phone, then at 200 percent zoom and at a narrow mobile width. Automated scans run alongside, but they find only part of what matters on a store.
- Findings report. Each issue is listed with the page, the steps to reproduce it, the WCAG criterion, a severity and who can fix it: us, the theme author, a plugin vendor or the payment provider.
- Fixes. We work in priority order: anything that blocks a purchase first, then anything that misleads, then polish. Fixes go into a child theme or a small site plugin so theme updates do not wipe them out.
- End-to-end retest. We place test orders again, the same way as at the start, and record the results.
- Handover. You get the updated report and a short note of what changed, where, and what to watch after updates.
If you have already had a general audit, we can start from that report rather than repeat it. Our WCAG audit service covers stores and non-store sites alike; this page is about the store-specific fix and retest work.
Retesting orders end to end, not page by page
A product page can pass every check on its own and still fail as part of a purchase. Focus might land in the wrong place after adding to cart. The coupon might clear the shipping choice. A redirect after payment might drop a screen reader user on a page with no heading. That is why our retest is a sequence, not a checklist.
For each journey we record the starting page, the product and variation chosen, the input method used, each step taken and where it succeeded or failed. We use the gateway’s test or sandbox mode on staging so no real cards are charged. On a live store, where staging is not possible, we agree a low-value test product and refund the orders afterward, with your approval.
The journeys normally include a guest checkout, a logged-in checkout, a failed payment followed by a successful one, a coupon that does not apply and one that does, and a change of shipping address at the last step. If you sell to businesses with purchase orders or quotes, we add that path too.
Records you keep, and the access we ask for
At the end you hold a record you can actually use:
- A findings report with each issue, its criterion, its status (fixed, partly fixed, third-party, not fixed) and how it was verified.
- The journey log from the final retest.
- A list of code changes with file locations, so another developer could follow them.
- Copies of the issue reports we wrote for plugin or gateway vendors.
- Notes for your team on keeping product content accessible: image descriptions, variation names, size guide formats.
From you we need administrator access to WordPress, access to the hosting or a staging copy, a list of your top-selling products and any odd ones (made-to-order, bundles, pre-orders), the names of the payment and shipping plugins you rely on and a person who can approve test orders and refunds. If your developer or agency also works on the site, an introduction helps us avoid editing the same templates.
Caching deserves a mention here. Cart and checkout pages should be excluded from page caching, and a misconfigured cache can make status messages and cart updates look broken during testing. Our note on which WooCommerce pages to keep out of the cache explains the usual exclusions.
How to judge the result, and mistakes stores make
You do not need to be technical to check our work. Unplug your mouse, open your store and try to buy something. Can you always see where you are? Do you reach the payment step? Then ask a colleague to try it with VoiceOver on an iPhone. If both of you can finish, and the report explains what still depends on a third party, the work did what it should.
Be skeptical of any result that is just a scanner score. A clean automated score on the cart page says little about whether the variation picker announces a price change. Also be wary of these common mistakes:
- Fixing the homepage and ignoring the checkout. The checkout is where barriers cost both the shopper and you a sale.
- Adding plugins to fix plugins. Another layer of script on the cart page often adds new problems.
- Editing core WooCommerce or parent theme files. Changes vanish on the next update. They belong in a child theme or a site plugin.
- Forgetting the content. Product images without useful descriptions and variation names like “Option 3” undo good code.
- Testing on a cached, logged-in admin view. Shoppers see something different. Test logged out, as a customer.
Some of these are covered from a store owner’s point of view in our post listing the WooCommerce barriers we see most.
WooCommerce accessibility fixes: what to do yourself and what to hire out
A store owner can do a lot alone: write real product image descriptions, rename variations sensibly, remove a slider nobody uses, choose plugins with care and run a keyboard test before every sale season. Where most owners need help is the code: template overrides, ARIA live regions for cart updates, focus management in drawers and modals, and judging which plugin is the source of a fault.
Whoever you hire, ask them:
- Will you test real purchases with a keyboard and a screen reader, or only scan pages?
- How will you handle the payment fields you cannot edit, and will that appear in the report?
- Where will your fixes live, and what happens to them when WooCommerce or the theme updates?
- Do you test both guest and logged-in checkout, and the account pages?
- Will you tell us if a plugin should be replaced rather than patched?
Most store fixes also touch forms beyond the checkout, such as wholesale signup, back-in-stock alerts and product inquiry forms. Those follow the methods on our accessible form fixes page. Larger code changes we treat as standard remediation of audit findings, with the same retest at the end.
A note on law, since store owners often ask. A store that sells to the US public is a business open to the public, and when demand letters arrive, the technical benchmark they cite is usually WCAG 2.1 or 2.2 AA. Nothing here is legal advice; we are developers, not attorneys. If you have received a letter, a lawyer should handle it; we handle the technical work and the record of it.
Keeping the store accessible after updates and new products
WooCommerce, payment gateways and themes update often. A new release of a swatches plugin can undo a labeling fix. A seasonal promo bar can cover the focused element (2.4.11 Focus Not Obscured). A new product type can introduce a form nobody has tested. An accessible WooCommerce store stays that way only if someone keeps checking.
We recommend a short retest of the key purchase journeys after major WooCommerce or gateway updates and before big sale periods, plus a lighter monthly look at new product pages. Our ongoing accessibility checks include this, and they fit alongside general WooCommerce support such as updates, backups and order troubleshooting. When updates are tested on a staging copy first, these regressions are caught before shoppers meet them. If you are unsure what that involves, our guide to using a WordPress staging site explains it in plain terms.
Accessibility on a store is never finished in the sense of a box ticked once. It is finished in a more useful sense: you know where every journey stands, you know what changed, and you have a record that shows the work was done with care. For the technical text of each criterion mentioned here, the WCAG 2.2 specification is the source we work from.
Forms, checkout and online stores: Guides
Step-by-step guides on the individual tasks behind this service:
- Ecommerce Accessibility: The Whole Shopping Journey
- WooCommerce Accessibility Issues and How to Fix Them
- Accessible Checkout: A Field-by-Field Guide for Stores
- Accessible Form Design: Labels, Groups and Layout
- Accessible Error Messages on Website Forms
- CAPTCHA Accessibility and Alternatives That Work
- Accessible Product Pages: Images, Swatches, Add to Cart
- Shopify Accessibility: What Store Owners Can Fix
- Accessible Booking Forms: Dates, Time Slots, Confirmation
- WordPress Contact Form Accessibility: What to Check
- Product Filter Accessibility for Online Stores
- Chat Widget Accessibility: Live Chat That Works for All