WooCommerce sits underneath a large share of small-business e-commerce on the web. It is free, runs on top of WordPress, and is flexible enough that a hobbyist can launch a store in an afternoon. That same flexibility is also why WooCommerce stores show up in ADA demand letters and EAA complaints out of proportion to their share of the market. The owner picked a theme that looked nice, installed five plugins to add the features they needed, and the combined output failed a half dozen WCAG criteria nobody on the team has ever heard of.

We have audited a long string of WooCommerce stores in the last six months — small bakeries, indie clothing brands, a couple of supplement shops, a regional book chain, a handmade-jewelry seller, a coffee roaster. Every one of them had the same six problems. None of the owners knew. Every one of the owners is exposed to the same demand-letter campaigns that have been hitting Shopify and BigCommerce stores for the last two years. This post is the list, in order of how often we see it, with what each one costs and how a non-developer can fix it without rebuilding the store.

None of this is legal advice. If you have already received a demand letter, talk to an attorney with ADA Title III or EAA experience before responding.

1. Product images with alt text that says nothing

The number-one finding across every WooCommerce audit is product images whose alt text is the file name or the product name copy-pasted twenty times in a row. Lighthouse passes the page because the alt attribute is present. A screen reader user shopping the store hears "DSC_4271, DSC_4271, DSC_4271" or "Blue Cotton T-Shirt, Blue Cotton T-Shirt, Blue Cotton T-Shirt" depending on which is worse. They cannot tell the listings apart and they leave. This is the failure pattern most commonly cited in recent demand letters against e-commerce stores.

WooCommerce makes this worse than necessary because the default image upload flow does not require alt text and most themes use the product name as the fallback. The fallback is technically present and technically wrong, in the sense that a screen reader user gets the same string for every product variant or color swatch on the page.

What to do without rewriting the theme: open every product, click each image in the WordPress media library, and write alt text that describes what is visually different about that specific image. For a product page with five images of the same shirt from five angles, alt text might be "front view of blue cotton t-shirt", "back view showing pocket detail", "close-up of stitched neckline", "model wearing shirt with jeans for scale", "flat-lay of folded shirt". For a category page showing many products, the alt text on each thumbnail should distinguish the product, not repeat the title that already appears as text next to it. We wrote a longer guide on alt text patterns that pass and fail if you want examples that go past the basics.

2. The "Add to Cart" button is a div, not a button

The second-most-common finding is themes and customizations that render the Add to Cart action as a styled div with an onClick handler instead of a real HTML button. Visually it looks exactly the same. With a keyboard, the user cannot tab to it. With a screen reader, the device says nothing — there is no role to announce. The store has effectively put the most important action behind a wall.

This typically shows up in heavily customized themes, in page builders like Elementor or Divi when the developer used a generic "container" element with a click action, and in custom shop layouts that override the WooCommerce loop template. WCAG criterion 2.1.1 Keyboard requires every interactive element to be operable with a keyboard, and 4.1.2 Name, Role, Value requires it to announce its role to assistive technology. A div with onClick fails both, as our React tutorial accessibility post explains for a related framework, but the underlying problem is identical in WordPress and PHP.

What to do without rewriting the theme: ask whoever built the site to change every Add to Cart, Buy Now, Apply Coupon, and Checkout element to use a real or tag with the right href. If you are using Elementor or Divi, switch the affected element from a "Click box" or "Container with link" to the dedicated "Button" element, which renders semantic markup. If you are using a Shopify-style theme that ships its own product card template, the line you are looking for in the template is usually the loop start in content-product.php — bring it to your developer with a screenshot of the keyboard test.

3. Coupon code, quantity, and shipping fields with no labels

WooCommerce checkout pages are generated by a mix of core templates, the active theme, and any plugins that add fields (subscription managers, shipping calculators, gift wrap, address validators). Every one of those layers can introduce a form field that is missing a label or has a label associated only by visual proximity. The result is a checkout where a screen reader user hears "edit, edit, edit, edit" instead of "Email, edit", "Phone, edit", "Address line 1, edit".

The other failure mode here is fields that have visible labels in the design but use placeholder text instead of a real element. The placeholder disappears as soon as the user types, so a user who pauses to switch tabs comes back to a blank field with no indication of what it was for. This is also what happens to a user with cognitive disabilities or a non-native speaker who needs to re-read the label after starting to fill it in.

What to do without rewriting the theme: install a checkout audit. We use the WAVE browser extension for this — load the cart, then load the checkout, and look for the orange "missing form label" markers. For each one, look up the plugin or theme component that owns the field and either configure a label in its settings panel (most plugins have one) or replace the plugin with one that ships labels by default. Our deeper accessible forms guide covers the patterns that pass screen reader testing.

4. The mini-cart and ajax updates that nobody hears

A WooCommerce store with ajax-enabled cart updates is a great experience for sighted users — click Add to Cart, see the cart number tick up in the header, keep shopping. For a screen reader user, the same interaction makes no sound. The DOM has updated, the visual count has changed, but no live region announced "1 item added to cart" so the user has no idea anything happened.

This is a violation of WCAG 4.1.3 Status Messages. It is also one of the most consistent reasons that screen reader users describe ecommerce sites as "broken", because the entire purchase flow is a sequence of silent state changes. The widely deployed WooCommerce themes from Storefront, Astra, and OceanWP all ship without an aria-live region around the mini-cart, and most theme customizations do not add one.

What to do without rewriting the theme: ask your developer to add a small live region to the cart UI. The exact change is one line of HTML — a wrapper element around the mini-cart count or notification area with aria-live="polite" and aria-atomic="true". After the change, every cart update should be announced. This same technique applies to coupon application messages, stock-status updates on product pages, and the "successfully added to wishlist" toasts that show up after a click. If you are working with a developer, our post on automating accessibility fixes in CI covers how to keep regressions from coming back the next time the theme is updated.

5. Color contrast that looks fine on the homepage and fails on every product page

WooCommerce stores tend to be designed once for the homepage and then forgotten on the templated product, category, and checkout pages. The homepage gets the brand colors set deliberately. The product page inherits whatever defaults the theme shipped with — light grey "Sale" badges on white backgrounds, light brand-colored "Add to Cart" buttons whose label fails contrast, "Free shipping over $50" banners in pastel beige.

Color contrast is one of the few WCAG criteria that automated tools detect reliably. WCAG 2.2 Level AA requires a contrast ratio of 4.5:1 for normal-size text and 3:1 for large text and meaningful graphical elements. The most-cited demand-letter contrast failures we see in WooCommerce stores are sale-price badges (often pink or red text on a pastel background), discount banners in light theme accent colors, and the small print under product cards that describes shipping eligibility.

What to do without rewriting the theme: run a contrast pass on a product page, a category page, and the cart page using a tool like the Chrome DevTools color picker or the WebAIM Contrast Checker. For each failure, adjust the color in the theme customizer rather than in CSS — most modern WooCommerce themes expose primary, accent, and badge colors directly. We have a longer walkthrough in our color contrast guide if you want screenshots of the specific values that pass and fail.

6. Plugins that override accessible defaults

The WooCommerce plugin ecosystem is enormous, and plugin authors face no centralized accessibility review. A few patterns show up over and over: subscription plugins that render their own checkout fields without labels, currency switchers that use clickable spans instead of select elements, product filter widgets that nest five layers of div onClick handlers, and payment gateways that load iframes with form fields the parent page cannot reach for keyboard or screen reader users. The store owner installs each plugin to solve a real problem and ends up with a stack of accessibility regressions they did not know they were buying.

The biggest culprits we see across audits are filtering and faceted search plugins (WooCommerce Product Filter, BeRocket, Annasta), AJAX cart plugins that override the default cart and lose the live region, and overlay widgets like accessiBe and UserWay that the owner installed thinking they would help. Our why overlay widgets do not work post covers that last category in detail, including the specific demand letters in which overlay widgets were the named defendant.

What to do without rewriting the theme: before installing any new WooCommerce plugin, search the plugin's name plus "accessibility" and check whether the support forum or recent reviews flag any issues. If you have already installed a long stack, audit the plugins that touch checkout and product display first — those are the pages that ship in demand letters. Replace any plugin that fails a basic keyboard test (tab through every interactive element on the page; can you reach all of them and operate them with Enter or Space?) with an alternative that passes.

What we recommend, in order

If you run a WooCommerce store and you have read this far, the order we recommend is: fix the alt text on product images, replace any div-as-button with a real button or link, audit the checkout fields for missing labels, add the live region around the mini-cart, run a contrast check on three template pages, and uninstall any plugin that introduces an overlay widget. None of these require rewriting your theme. Each one closes a specific failure that has shown up in a specific demand letter against a small WooCommerce store in the last twelve months.

If you want a starting point that covers the rest of the site, our WordPress accessibility guide walks through the same audit at the platform level, and the WordPress WCAG audit checklist collects the recurring failures we see across themes, page builders, and form plugins in a structured criterion-by-criterion format. If you are running an e-commerce checkout flow and want to be sure your specific checkout passes, our accessible e-commerce checkout guide goes deeper into the checkout-specific patterns. And if you have already received a demand letter or are worried about getting one, our post on ADA lawsuits and small business covers the realistic scope of risk and what kind of response the demand letter is actually asking for.

We're building a simple accessibility checker for non-developers -- no DevTools, no jargon. Join our waitlist to get early access.

Related Reading

• WordPress Accessibility Guide -- the platform-level audit that sits underneath every WooCommerce store
• Accessible E-commerce Checkout Guide -- a deeper walkthrough of the checkout flow patterns that show up in demand letters
• ADA Lawsuits and Small Business -- realistic scope of e-commerce demand-letter risk and how to think about response cost