A WooCommerce store becomes ADA compliant when it meets WCAG 2.1 AA at minimum, which means keyboard-only navigation works everywhere a mouse does, every product image has real alt text, form fields have visible labels, color contrast hits a 4.5:1 ratio for body text, and nothing on the page depends on color alone to convey meaning. There is no official government certificate for this. Courts and plaintiffs’ attorneys use WCAG as the yardstick, and an ecommerce site that fails several of those points on a product or checkout page is the profile that gets sued in 2026.
Why Ecommerce Sites Are the Biggest Target Right Now
Website accessibility lawsuits stopped being a niche legal issue a few years ago. According to Level Access’s litigation tracking, 3,117 federal ADA website accessibility lawsuits were filed in 2025, a 27% jump from 2024, and website claims now make up 36% of all ADA Title III federal filings, up from 28% the year before. Combined with state court filings, the total cleared 5,000 for the year.
UsableNet’s monthly tracker puts the pace even more starkly: 4,928 lawsuits in 2025 alone, and 401 more in July 2026 by itself. Retail and ecommerce sit at the top of the target list, ahead of restaurants, travel, healthcare, and banking. That ranking is not a coincidence. Ecommerce pages are built almost entirely from the components that trip up screen readers and keyboard users: filters, image galleries, quantity steppers, and multi-step checkout forms.
What WCAG 2.2 AA Actually Requires (Not the Vague Version)
Most articles on this topic stop at “make your site accessible” without saying what that means on an actual page. Here is the list that a real audit checks against a WooCommerce store, stripped of jargon:
- Every product photo, thumbnail, and swatch has alt text that describes the item, not “image1.jpg” or a blank tag
- Text and background colors hit at least a 4.5:1 contrast ratio, which rules out light gray text on white, a favorite of minimalist product pages
- A shopper can tab through the entire filter panel, add-to-cart button, and checkout form using only a keyboard, with a visible focus outline at every stop
- Form fields (shipping address, card number, coupon code) have actual
<label>elements, not placeholder text that disappears the moment someone starts typing - Error messages on checkout describe what is wrong and where, not just a red border around the field
- Sale badges, stock warnings, and size availability are not communicated by color alone (a red dot for “out of stock” needs text or an icon alongside it)
- Video content, including product demo clips, has captions
None of this is exotic. It is closer to a checklist than a redesign, and most of it costs nothing to fix once someone has actually gone looking for it.
Where WooCommerce and Elementor Builds Usually Fail
The components that make a WooCommerce store feel modern are the same ones that most often ship without accessibility built in. When we built Kayzur’s fashion ecommerce site on WordPress with Elementor and WooCommerce, the brief centered on exactly these pieces: a product filtering system, optimized product pages, and a streamlined cart and checkout flow. Those three feature types (filters, product pages, and checkout) are also the three places a WCAG audit spends the most time on any ecommerce site, because they are where interactivity concentrates.
A filter panel built as clickable divs instead of real checkboxes or buttons often can’t be reached by keyboard at all. A product gallery that swaps images on hover, with no equivalent for tap or focus, locks out anyone not using a mouse. Checkout forms assembled from a page builder’s default field styling frequently drop the label-to-input association that screen readers rely on to announce what each box is for. None of these are visible problems if you are clicking through the site yourself with working eyesight and a mouse. They are the first three things a screen reader user or a keyboard-only user hits.
This is also where the UI/UX layer matters more than the plugin choice. Elementor, Divi, and native WooCommerce templates can all be built accessibly or inaccessibly. Our UI/UX design process treats contrast ratios, focus states, and label structure as part of the visual design brief from the start, not a punch list handed to a developer after launch. Retrofitting accessibility into an existing theme is real, billable work. Designing it in from the first Figma file is close to free.
Do Accessibility Overlay Widgets Actually Protect You From a Lawsuit?
A one-line JavaScript widget that promises instant ADA compliance is the most common thing store owners buy when a lawyer’s letter arrives. It is also, by the numbers, not working. UsableNet’s July 2026 data shows 113 defendants were sued that same month despite already running a third-party accessibility widget at the time of the suit. Widgets can adjust font size and add a contrast toggle, but they cannot rewrite a filter panel’s underlying markup or add a missing label to a checkout field. Plaintiffs’ attorneys know this, and several firms now specifically target sites running known overlay products.
| Approach | Typical Cost | What It Actually Fixes | Lawsuit Risk |
|---|---|---|---|
| Overlay widget | $29 to $500+/month | Font size, contrast toggle, cosmetic adjustments | Still high; documented lawsuits against widget users |
| Automated scan only | Free to a few hundred dollars | Flags roughly 30 to 40% of real WCAG issues; catches nothing that requires judgment | Moderate; leaves the manual-testing issues untouched |
| Manual audit plus code-level fixes | Project-based, scoped to the site’s page templates | Markup, labels, keyboard flow, focus order, contrast at the theme level | Lowest; addresses the actual WCAG success criteria courts reference |
The gap between the first row and the third is the entire reason widgets keep getting sued. They treat accessibility as a display setting instead of a structural property of the HTML.
A Practical Remediation Path for an Existing Store
Fixing an existing WooCommerce store doesn’t require a full rebuild. It goes in roughly this order:
- Run an automated scanner (WAVE, axe DevTools, or Lighthouse’s accessibility panel) across the homepage, a category page, a product page, and checkout to get a baseline list of obvious violations
- Do a manual keyboard-only pass through the same four page types, noting anywhere the tab key skips an interactive element or gets stuck
- Fix contrast and missing alt text first, since these are typically the highest-volume, lowest-effort items
- Rebuild the filter panel and checkout form markup so labels, roles, and focus order are correct, which usually requires a developer rather than a design tweak
- Publish a short accessibility statement describing what standard the site targets and how to report an issue, which several courts have treated as evidence of good-faith effort
- Add an accessibility check to the QA process for every new product page or theme update, since a store that fixes today’s issues but reintroduces the same ones next quarter hasn’t actually solved anything
Step four is where most DIY attempts stall, because page builder plugins don’t expose a friendly settings panel for ARIA roles and focus order. It’s markup-level work, closer to development than to picking a theme option.
What This Actually Costs and How Long It Takes
A full manual audit and remediation on a mid-sized WooCommerce store (roughly 4 page templates, a filter system, and a multi-step checkout) typically runs a few weeks once you account for the manual keyboard and screen-reader testing pass, not just the automated scan. That is a similar scope and timeline to the Kayzur build‘s own four-week project window, which covered comparable components: filtering, product pages, and checkout. The difference is that accessibility work is corrective rather than net-new, so it tends to land at the lower end of that range once the audit findings are prioritized. Settlement costs for getting this wrong run considerably higher: Level Access cites a Fashion Nova class action that settled for $5.15 million, and even a case with no damages awarded commonly costs five figures in legal defense before it’s resolved.
For a business already planning a WooCommerce build or redesign, folding accessibility into that same project timeline costs a fraction of what a separate remediation engagement does later, for the same reason retrofitting is always more expensive than designing something correctly the first time. It’s the same principle we’ve written about for trauma-informed design: building for the visitor who isn’t having an easy day, rather than assuming everyone arrives with full vision, full motor control, and a mouse, is cheaper the earlier it happens.
Does This Apply to Every Ecommerce Store, or Just Large Ones?
There is no small-business exemption written into the ADA, and Level Access’s data shows plaintiffs increasingly targeting companies below the revenue thresholds that used to feel safe. Businesses in the broader ecommerce space are the single most-targeted category in both the UsableNet and Level Access tracking, ahead of restaurants, travel, and financial services. Store size determines how expensive a lawsuit is to settle. It doesn’t determine whether a plaintiff’s attorney will find the site in the first place, since most of these suits originate from automated scans run against thousands of sites at once, not from a person manually browsing a small store and getting frustrated.
Frequently Asked Questions
Does WCAG 2.2 legally apply to my WooCommerce store?
WCAG isn’t itself a law, but courts and the Department of Justice treat WCAG 2.1 AA as the practical benchmark for ADA Title III compliance, and WCAG 2.2 AA as current best practice. There’s no certification process; compliance is judged by whether the site meets those success criteria when tested.
Will an accessibility overlay widget stop me from getting sued?
Not reliably. UsableNet documented 113 businesses sued in a single month (July 2026) despite already running a third-party overlay widget. Widgets adjust display settings but don’t fix underlying markup issues like missing labels or broken keyboard navigation, which is what most lawsuits actually cite.
How much does it cost to make an existing WooCommerce store compliant?
It depends on the number of page templates and how the filter and checkout components were originally built, but it’s typically scoped as a project against the site’s existing templates rather than priced per page. It’s almost always cheaper than a single lawsuit settlement or defense.
What’s the difference between an automated scan and a manual accessibility audit?
An automated scanner like WAVE or axe catches roughly a third to 40% of real WCAG issues, mostly contrast and missing alt text. Keyboard navigation, focus order, and screen-reader announcement issues require an actual person testing the site by hand, since a script can’t judge whether a screen reader announces a filter correctly.
Do I need to redesign my whole site to fix this?
No. Most remediation happens at the markup and component level: labels, alt text, contrast values, and focus order on existing page templates. A full redesign is only necessary if the underlying theme or page builder structure makes those fixes impossible without rebuilding the component from scratch.
