Ecommerce accessibility lawsuits increased by roughly 300% between 2018 and 2023, according to data from UsableNet. Most of those lawsuits target mid-market retailers — not just enterprise brands. The pattern is clear: once your store has revenue worth pursuing, accessibility deficiencies become legal exposure, not just UX problems.
The practical case for accessibility is even simpler than the legal one. About 26% of US adults live with some form of disability. Stores that work well with screen readers, keyboard navigation, and high-contrast modes convert that population. Stores that don’t, don’t.
What WCAG 2.1 Level AA Actually Requires
WCAG (Web Content Accessibility Guidelines) 2.1 Level AA is the legal standard referenced in most ADA-related web accessibility cases in the US. It’s also the minimum standard courts have applied when ruling on website accessibility claims under the Americans with Disabilities Act.
Level AA compliance organizes around four principles: Perceivable, Operable, Understandable, and Robust (POUR). In practical ecommerce terms, this translates to specific requirements across five problem areas that stores consistently fail.
Image Alt Text
Every product image needs an alt attribute that describes the image’s content in context. “Product image” is not a description. “Blue canvas tote bag with leather handles, 14 inches wide” is a description.
The failure mode on most ecommerce stores: images uploaded via WooCommerce’s media library with filenames like IMG_3842.jpg and no alt text filled in. Screen readers announce the filename, which communicates nothing. For a store with 500 products, retroactively adding alt text is a significant project — but it’s a legal requirement, not an optional improvement.
Variable product images — the images that swap when a customer selects a color or size — need alt text for every variant image, not just the default.
Form Field Labels
Every input on a checkout form must have a visible label associated with it via the for attribute or an aria-label. Placeholder text is not a label — it disappears when the user starts typing, leaving screen reader users with no indication of what field they’re filling in.
This is one of the most common accessibility failures on WooCommerce checkout pages. Default WooCommerce provides labels, but many customized checkouts — built with checkout plugins or custom CSS that hides labels for a “cleaner” design — remove visible labels and rely on placeholders. That’s both an accessibility violation and a conversion problem. Visible labels outperform placeholder-only forms in A/B tests.
Keyboard Navigation
A user who cannot use a mouse must be able to navigate your entire store using only a keyboard — Tab to move between elements, Enter to activate, Space for checkboxes. This includes the product grid, add-to-cart buttons, color/size selectors, the cart, the entire checkout, and the account area.
Test this by unplugging your mouse and tabbing through your store. If focus indicators are invisible (many themes remove the browser’s default focus outline for aesthetic reasons), keyboard-only users have no idea where they are on the page. Removing focus outlines without providing alternative visible focus styles is an automatic WCAG failure.
The operator of a specialty food WooCommerce store received an accessibility demand letter in late 2022. Their site had no image alt text, placeholder-only form fields, and focus indicators that had been removed by their theme developer “to look cleaner.” They settled for $8,500 in legal fees plus a 90-day remediation agreement. The original cost to build with accessibility in mind would have been an extra 8–12 hours of development time.
Color Contrast
WCAG 2.1 AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold) against its background. For ecommerce stores, the common failures are:
- Light gray text on white backgrounds (common “clean” design aesthetic)
- Low-contrast call-to-action buttons
- Price text in muted colors against product card backgrounds
- Disabled button states that fall below minimum contrast
Use the WebAIM Contrast Checker or browser DevTools’ color contrast analysis to audit your store. This takes about two hours to do comprehensively and catches most violations before they become legal exposure.
Meaningful Error Messages
When a form submission fails — wrong card number, missing required field, out-of-stock item added to cart — the error message must be specific, must identify which field caused the error, and must be announced to screen readers via aria-live regions.
“Please check your submission” is not a meaningful error message. “Your card number appears to be invalid — please check digits 13–16” is. WooCommerce’s default error messaging is adequate for most situations, but checkout plugins and custom checkout implementations often replace or break the native error handling.
The WooCommerce-Specific Accessibility Gaps
WooCommerce core has improved significantly in accessibility over recent versions, but specific areas still require custom attention.
Product Variation Selectors
The default WooCommerce variation dropdowns are reasonably accessible, but variation selector plugins — which replace dropdowns with visual swatches — often are not. Color swatch plugins that use only visual color without a text label are inaccessible to screen reader users and fail color-only information requirements in WCAG 1.4.1.
If you use swatch plugins, the selected state must be programmatically determinable (ARIA), and each swatch must have a text equivalent (aria-label or title attribute).
Cart and Checkout Dynamic Updates
When a user updates their cart — changes quantity, applies a coupon, selects a shipping method — WooCommerce updates the totals via AJAX. For sighted users, this is smooth. For screen reader users, the update is silent unless an aria-live region announces that cart totals have changed.
WooCommerce has partial ARIA live region support, but implementations vary. Custom checkout designs that rebuild the cart interaction often lose this entirely.
Zoom and Mobile Touch Targets
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no"> disables user zoom — a WCAG failure. If your theme or a mobile plugin sets this to prevent “unwanted zooming,” remove it. Users who need to zoom to read content must be able to zoom.
Touch targets for interactive elements (buttons, links, form inputs) must be at least 44×44 pixels per WCAG 2.5.5. Small “remove item” icons in the cart, small size/color selectors, and close buttons on modals regularly fail this threshold on mobile-optimized designs.
James runs a WooCommerce clothing store and hired a developer to add color swatches to his variation selectors. The plugin was visually polished — customers liked the look. Three months later, he ran a screen reader test for the first time and discovered that none of the color swatches had labels: a screen reader announced “undefined” for each one. Adding aria-labels to the swatch elements took about four hours. Running the test first would have cost the same.
Accessibility Plugins — What They Can and Can’t Do
Overlay plugins (AccessiBe, UserWay, AudioEye) add a widget to your site that claims to fix accessibility issues automatically. These tools have been explicitly criticized by the National Federation of the Blind and multiple accessibility advocacy organizations as inadequate — and have been named in lawsuits despite their presence on sites.
What overlays actually do: provide some partial fixes for the most common low-effort issues while creating new ARIA conflicts that can make screen reader navigation worse. They cost $49–$500/month. They don’t solve the underlying accessibility problems and they don’t provide meaningful legal protection.
What actually works: building accessible markup in the first place, then testing with real assistive technologies (NVDA + Chrome on Windows, VoiceOver on Mac/iOS) before launch. This is a development practice, not a plugin.
Testing Your WooCommerce Store for Accessibility
A basic accessibility audit doesn’t require hiring a specialist for the first pass. Tools that catch most automated violations:
- WAVE (browser extension) — highlights missing alt text, label issues, and contrast failures visually
- axe DevTools (browser extension) — finds WCAG violations in the DOM with code references
- Lighthouse (Chrome DevTools) — provides an accessibility score and specific failures
Automated tools catch approximately 30–40% of accessibility issues. The rest require manual testing — keyboard navigation, screen reader testing, and zoom behavior. A comprehensive audit takes 4–8 hours for a typical WooCommerce store.
If you want a fast read on where your store stands before investing in remediation, Honest includes site health checks that surface major technical gaps.
For WooCommerce stores built with accessibility as a requirement from the start — not patched in after complaints — our custom WooCommerce development addresses WCAG 2.1 AA compliance at the code level. Or start with our fixed-price packages which include accessible markup by default.
FAQ
Is my WooCommerce store legally required to be accessible? In the US, federal courts have ruled that websites of businesses open to the public are covered by the ADA. The specific legal standard isn’t fully settled, but WCAG 2.1 Level AA has been applied as the benchmark in numerous settlements and rulings. Stores with US customers have meaningful legal exposure if they fail basic accessibility standards.
What is the most common accessibility failure on ecommerce stores? Missing or inadequate image alt text is the single most common failure by volume, followed by form fields without visible labels. These two issues alone account for a large majority of the accessibility complaints that turn into legal demand letters.
Do accessibility overlays like AccessiBe make my site compliant? No, not reliably. Overlay tools have been repeatedly demonstrated to leave significant accessibility barriers intact and sometimes introduce new problems. Multiple organizations representing blind and disabled users have called these tools ineffective. They are not a substitute for accessible code.
How long does it take to make an existing WooCommerce store WCAG compliant? Depends entirely on the current state of the site. Stores with well-structured markup, existing alt text practice, and reasonable theme code can often reach AA compliance with 20–40 hours of remediation work. Stores built on page builders with extensive plugin stacks and no accessibility practice may require a rebuild — the structural problems are too deep for patching.
Does accessibility affect my SEO? Yes, indirectly but meaningfully. Alt text improves image SEO. Semantic HTML structure (proper heading hierarchy, labeled forms) improves how search engines understand your content. Page speed improvements (many overlap with accessibility improvements) are direct ranking signals. Accessible stores tend to perform better in search than inaccessible ones, all else being equal.