Mira Digital Commerce Agency

"Is our site ADA compliant?" It's one of the questions merchants ask us most, and they usually want a yes or a no.

I wish I could give them one. The honest answer is that ADA compliance is a legal question, and nobody, including us, can test their way to a legal conclusion. What we can test, page by page and criterion by criterion, is how well your site conforms to the Web Content Accessibility Guidelines (WCAG).

That might sound like hair-splitting, but it changes what you should expect from any accessibility partner. It also explains why so many merchants who thought they were covered still end up with a demand letter. 

In our Guide to ADA Conformance for Ecommerce, we covered the legal background, and the WCAG standard. This post picks up where that guide left off, with the part most merchants underestimate: accessibility doesn't stay fixed once you fix it.

Conformance is technical. Compliance is legal.

WCAG conformance is something we can measure. Each WCAG success criterion either passes or fails on a given page, and you can document that result and check it again next month.

ADA compliance works differently. The ADA is a civil rights law from 1990, and it doesn't spell out a technical standard for private websites. Courts and the Department of Justice commonly reference WCAG, but whether your business complies is decided case-by-case, usually through litigation or a settlement.

 

 WCAG conformance ADA compliance 
What it is A technical standard from the W3C, the group that sets web standardsA legal question under a 1990 civil rights law 
Who decides Testing against published success criteria Courts, through litigation or settlements 
Can it be measured? Yes, criterion by criterion Not directly; it depends on legal interpretation

 

So if conformance can't guarantee compliance, why bother? Because WCAG gives you something concrete to test and fix, instead of a yes-or-no nobody can give you.  And every barrier you fix is one less thing standing between a customer and checkout.

Why no one can promise you ADA compliance

The litigation numbers make this point better than I can. Plaintiffs filed 3,117 federal website accessibility lawsuits in 2025, up 27% from 2,452 in 2024, according to Seyfarth Shaw's ADA Title III tracking. Add key state courts and UsableNet counted more than 5,000 digital accessibility lawsuits that year.

Three things in that data should matter to any merchant:

  • Getting sued once doesn't protect you from getting sued again. UsableNet counted 1,427 lawsuits in 2025 against companies that had already faced an accessibility claim. They settled or fixed something, and the next claim came anyway.
  • Overlays and widgets don't hold up. AudioEye, itself an accessibility vendor, reports that 38% of 2025 lawsuits targeted businesses using a toolbar or widget as their accessibility solution (2026 Web Accessibility Litigation Report). If a plugin promised you compliance, that number is worth sitting with.
  • Online stores are the main target. Ecommerce sites remain the largest share of defendants, and the reason is simple: a barrier on a product page or in checkout directly stops someone from buying.

Whether you comply depends on courts, on plaintiffs and on every change your team makes to the site from here on. Good testing finds and fixes barriers. It can’t take it to zero, and you should be wary of anyone who says otherwise.

 

image (4).webp

The web is actually getting less accessible

You'd expect the web to get a little more accessible every year. In 2026 it went backwards. The WebAIM Million, an annual scan of the top one million home pages, found errors per page rose about 10% from the year before, and nearly every page it checked had detectable WCAG failures.

The reason is mostly complexity. Pages keep getting bigger, and every carousel, filter, widget and tracking script you add is one more place for accessibility to break.

Ecommerce feels this more than most. Shopping sites rank among the worst performers in WebAIM's data, largely because of the platforms, third-party libraries, ad networks and tracking tools they rely on (analysis by Nexer Digital). If you've ever counted the scripts loading on your own product page, that won't surprise you.

AI-assisted development adds to the pile. Teams are shipping more code, faster, and accessibility analysts have pointed to "vibe coding" as a likely factor (QualityLogic, April 2026). We use AI in our own QA process, so I'm not knocking the tools. Faster output just means more to check.

And a scanner only catches part of the problem, so the real picture is worse than these reports show.

Why a one-time audit won't cover you

An audit is a snapshot. It tells you where your site stood on the day it ran. Your store doesn't stand still: new products, seasonal promotions, theme updates, new apps, another marketing pixel. Any one of them can bring back a barrier that was fixed months ago.

The risk isn't concentrated on your homepage either. AudioEye reports that 64% of accessibility lawsuits cite violations on interior pages, like product pages or account dashboards (2026 Web Accessibility Litigation Report). Those are the pages that change most often.

From a QA point of view, the most frustrating part is that the most common failures are also the easiest to bring back. Low-contrast text, missing alt text, unlabeled form fields and empty buttons have topped the WebAIM Million every year since 2019. None of them are hard to fix. They're hard to keep fixed unless someone checks for them on every release.

 

image (3).webp

How we test accessibility at Mira

Typically, our QA team tests against WCAG 2.1 and 2.2 Level AA success criteria. We use three kinds of testing, because each one catches things the others miss:

  • Automated scans with axe DevTools. Fast, and good at flagging code-level issues like missing labels, low contrast and empty buttons.
  • Manual HTML review, with help from AI agents. A person on our team checks how the page is built: whether headings, buttons, menus and pop-ups make sense to assistive technology, which a scanner can’t judge on its own.
  • Screen reader testing. We go through real shopping flows (browsing, adding to cart, checking out) the way someone using assistive technology would.

Automated tools give us speed. Manual and screen reader testing tell us whether a real customer can actually get from your homepage through checkout.

Five questions to ask any accessibility partner

Whether you work with us or someone else, these questions will tell you quickly whether you're getting real accessibility work or a sales pitch:

  1. Which standard do you test against? You want a specific WCAG version and level. "ADA compliant" isn't a testing standard.
  2. How much of your testing is manual? Automated tools miss a lot, especially in keyboard navigation and screen reader behavior.
  3. What happens after launch? Ask how accessibility gets re-checked as the site changes, and how often.
  4. Does it cover the full purchase path? Search, filters, product pages, cart and checkout matter more than the homepage.
  5. Do you rely on an overlay or widget? If the answer is yes, ask what's actually being fixed in the code.

Accessibility is ongoing work

No amount of testing can guarantee you'll never get a demand letter. What testing does is catch barriers early, so they get fixed before they cost you a customer. 

That's the part I'd encourage every merchant to focus on. Every barrier we remove is a shopper who can finish their order instead of giving up and buying somewhere else. 

If you want to know where your store stands today, talk to our team about accessibility testing.

 

Disclaimer: This article is for informational purposes only and is not legal advice. Consult a qualified attorney about your specific legal situation.

Author: Maia Schneider - Head of QA Practice - 10/7/2026

We would love to hear from you

Stay connected:
Sign up for our newsletter