WooCommerce Accessibility: Fixing the Issues ADA Complaints Cite
Short answer: Most WooCommerce accessibility problems come from the theme, product images without useful alt text, variation swatches, checkout markup, and plugin-injected popups or sliders. Owners can fix content issues themselves; theme, swatch and script problems usually need a developer.
WooCommerce gives you a lot of control, and that cuts both ways. Your theme, your plugins and your content all affect accessibility, and each is a separate place where problems can start. This guide covers the WooCommerce areas that tend to come up in accessibility complaints, what you can usually fix yourself, and what usually needs a developer.
This is general information, not legal advice. For questions about a specific demand letter or claim, talk to an attorney. If you have received a letter, see Got an ADA website demand letter? first.
Where WooCommerce problems usually come from
WooCommerce is a plugin that sits on top of WordPress and a theme. A typical store also adds plugins for swatches, sliders, popups, reviews, payments and analytics. Any layer can introduce barriers, and the layers interact.
Complaints about online stores tend to focus on whether a shopper using a keyboard or screen reader can find a product, choose options, add it to the cart and pay. The success criteria involved are mostly the ones listed in the WCAG 2.1 AA checklist. Courts and settlements vary, and no tool or setting can guarantee a particular outcome.
Theme choice
Your theme controls headings, landmarks, focus styles, color contrast, menus and the markup around product grids. Switching themes later is expensive, so evaluate it early.
What to check in any theme, including its demo site:
- Can you tab through the header, menu, search and cart using only the keyboard, with a visible focus outline?
- Is there a "skip to content" link (WCAG 2.4.1)?
- Does each page have one logical heading outline? See headings and page structure.
- Do buttons and links meet text contrast requirements (WCAG 1.4.3)?
Themes advertised as "accessibility-ready" have passed a review process on WordPress.org, but that review covers the theme only, not your plugins or content. Treat it as a good starting point, not a conclusion. More detail is in WordPress accessibility: themes, plugins and what to check.
Product image alt text in the media library
Missing or unhelpful alt text on product images is one of the easiest issues to find and one of the easiest to fix (WCAG 1.1.1).
In WordPress, alt text is stored per image in the media library. Open Media, select an image, and fill in the Alternative Text field. Product gallery images and the main product image use that field.
Practical guidance:
- Describe what a shopper needs to know: "Navy wool crewneck sweater, front view", not "IMG_4821" or "sweater sweater buy sweater".
- Give each gallery image its own description (front, back, detail, in use).
- Purely decorative images can have empty alt text.
- Images that contain text, such as sale banners, need that text in the alt attribute or, better, in real page text.
- Alt text is separate from the image title and caption. Filling in the title does not fill in the alt.
If you have hundreds of products, a developer can help with a bulk process, but the wording still deserves human review. For writing tips, see How to write alt text for product images.
Variation selectors and swatch plugins
Variable products (size, color) are a common trouble spot. By default WooCommerce uses standard <select> dropdowns, which are generally keyboard and screen reader friendly when they have labels.
Swatch plugins replace those dropdowns with clickable color or image tiles. Problems that can appear:
- Swatches built from
<div>or<span>elements that cannot be reached by keyboard (WCAG 2.1.1). - No accessible name, so a screen reader announces nothing or only "button" (WCAG 4.1.2).
- Selection indicated only by a color or border change, with no text or programmatic state.
- Unavailable options that look faded but are not announced as unavailable.
A well-built swatch group exposes each option with a name and a state. For example:
<div role="radiogroup" aria-labelledby="color-label">
<span id="color-label">Color</span>
<button type="button" role="radio" aria-checked="true">Navy</button>
<button type="button" role="radio" aria-checked="false">Forest green</button>
</div>
You can test a swatch plugin in a few minutes with the keyboard and a screen reader. If it fails, check the plugin's settings for an option to fall back to dropdowns, which is often the simplest fix. Otherwise, ask the plugin vendor about accessibility or consider another plugin.
Quantity inputs
The quantity field is a small element with real consequences. Check that:
- It has a programmatic label. WooCommerce's default template includes one, but themes and plugins that override the template sometimes drop it (WCAG 3.3.2).
- Plus and minus buttons, if your theme adds them, are real buttons with names such as "Increase quantity" and "Decrease quantity" (icon buttons without labels).
- The field works by typing a number, not only by clicking the buttons.
- On the cart page, each line's quantity field identifies which product it belongs to. "Quantity" repeated five times is hard to use.
If template overrides in a child theme are the cause, this is a developer fix.
Cart and checkout: blocks vs. shortcodes
WooCommerce now offers a block-based Cart and Checkout alongside the older shortcode-based pages ([woocommerce_cart] and [woocommerce_checkout]). Which one your store uses depends on its age, settings and extensions.
Neither approach is automatically accessible. What matters is the final result:
- Check which version your pages use in the page editor, and review WooCommerce's current documentation for how its blocks are maintained.
- Some payment gateways and checkout extensions only support one approach. Switching can break them, so test in a staging copy first.
- Shortcode checkouts are more often affected by theme styling and template overrides. Block checkouts are more affected by extension compatibility.
Whichever you use, run the checkout end to end: labels on every field, error messages tied to the fields they describe, no keyboard traps, and clear confirmation. See accessible form labels and error messages and accessible checkout fixes.
Plugin-injected popups and sliders
Plugins that add promotional popups, cookie banners, chat widgets and homepage sliders often cause problems because they inject markup you do not control.
Common failures:
- A popup opens but keyboard focus stays behind it, or cannot leave it.
- No visible or working close button, or Escape does nothing.
- Sliders that auto-advance with no way to pause (see carousels and sliders).
- Content inside slides that is not reachable by keyboard.
- Banners that cover the checkout button on small screens.
Owners can often reduce risk by turning off auto-play, delaying or removing popups on product and checkout pages, and removing plugins they do not need. Fixing focus handling inside a plugin's script is a developer task. See cookie banners, popups and chat widgets.
Overlay widgets that promise one-click fixes are a different matter; read Do accessibility overlay widgets prevent ADA lawsuits? before relying on one.
What you can fix vs. what needs a developer
| Issue | Usually you | Usually a developer |
|---|---|---|
| Product image alt text | Yes, in the media library | Bulk processes |
| Heading choices on pages you edit | Yes | Theme-level heading structure |
| Descriptive link text in content | Yes | Template links |
| Auto-play on sliders, popup timing | Often, via plugin settings | Custom scripts |
| Swatch keyboard and name support | Maybe, via settings | Usually |
| Quantity field labels | Rarely | Yes, template overrides |
| Checkout field and error markup | Rarely | Yes |
| Color contrast | Content colors | Theme styles |
If you need help, hiring someone to fix website accessibility covers what to ask.
A simple test plan
Test in this order, on a staging copy if you can. Repeat after theme or plugin updates.
- Keyboard pass. Unplug the mouse. Tab from the home page to a product, choose a variation, add to cart, open the cart, and complete checkout with a test payment method. Follow the 5-minute keyboard test.
- Focus visibility. Confirm you can always see where focus is (WCAG 2.4.7).
- Screen reader pass. Run the same path with NVDA on Windows or VoiceOver on Mac. See screen reader testing basics.
- Zoom and mobile. Zoom the browser to 200% and test on a phone (WCAG 1.4.4; mobile zoom and reflow).
- Automated scan. Automated tools find only part of the issues, but they catch missing alt text, labels and contrast quickly. You can run a free scan, then verify the findings by hand.
- Record what you did. Keep dated notes of what was tested, what was found and what was fixed. See why a dated audit record matters.
For the W3C's own explanations of the standards, see the WCAG 2.1 specification. For the U.S. Department of Justice's guidance on web accessibility, see ada.gov.
Frequently asked questions
Is WooCommerce accessible out of the box?
WooCommerce's core templates include many accessibility features, but the finished store depends on your theme, plugins and content. Two stores on the same WooCommerce version can differ greatly. Test your actual pages rather than assuming.
Should I use the block checkout or the shortcode checkout?
Neither is automatically better for accessibility. The right choice depends on your theme, payment gateways and extensions, and how each renders in your store. Test both in a staging copy and complete a purchase with a keyboard and a screen reader before switching.
Do swatch plugins cause accessibility problems?
They often can, because they replace standard dropdowns with custom controls. Check that every swatch can be reached by keyboard, has a name, and shows which one is selected in a way that is not color alone. If a plugin cannot do this, fall back to standard dropdowns.
Will fixing these issues protect me from an ADA claim?
No one can promise that. Fixing common barriers and keeping dated records of your testing shows good-faith effort, but courts and plaintiffs vary in how they treat web accessibility. Consult an attorney about your specific situation.
Where should I start if I have limited time?
Start with the purchase path: product page, variation choice, cart and checkout. Fix missing labels, keyboard traps and popups that block those steps first. Then work on alt text across your catalog.
Related
- WordPress Accessibility: Themes, Plugins and What to Check
- How to Write Alt Text for Product Images That Helps Shoppers
- Accessible checkout: the fixes that matter most for online stores
- A 5-Minute Keyboard Accessibility Test for Your Online Store
Proof of Access provides technical accessibility assessments. We are not a law firm and nothing on this page is legal advice. If you have received a demand letter or a lawsuit, talk to an attorney.