The ADA doesn’t name a specific web accessibility standard anywhere in its text, since it was written in 1990 before the modern web existed. In practice, though, ADA website compliance means meeting WCAG 2.1 Level AA: that’s the benchmark courts, settlements, and Department of Justice guidance consistently point to, even though it’s never been formally codified into ADA regulations for websites.

Why there’s no official technical standard

Title III of the Americans with Disabilities Act requires “public accommodations” to be accessible, and courts have generally interpreted that to extend to websites and mobile apps, at least for businesses connected to a physical location or offering goods and services to the public. But because the statute predates the web, there’s no regulation spelling out exactly what an ADA-compliant website looks like technically. That gap has been filled informally: DOJ settlement agreements, consent decrees, and the overwhelming majority of court rulings reference WCAG 2.1 AA as the practical standard, even without it being formally written into ADA regulations.

The Department of Justice has issued guidance over the years affirming that the ADA applies to websites, and has referenced WCAG in various settlement agreements and technical assistance documents, but it has stopped short of issuing a formal regulation with the specificity businesses often want. That leaves WCAG 2.1 AA as an informal but well-established benchmark rather than a legally mandated checklist, a distinction that matters in court but rarely changes what a business should actually do, since the practical target ends up being the same either way.

Who has to comply

“Public accommodation” is interpreted broadly and generally includes retail sites, restaurants, hotels, healthcare providers, financial services, and many other business types with a public-facing website, regardless of company size. Very small businesses are pursued less frequently in practice simply because litigation tends to target sites with meaningful traffic or repeat plaintiffs’ attention, but there’s no formal small-business exemption written into the law the way there is under some other accessibility regulations.

There’s also an important practical distinction between businesses connected to a physical location and web-only businesses. Courts have been more consistent in applying the ADA to sites tied to a brick-and-mortar presence, since the “nexus” argument (that the website is an extension of a physical public accommodation) is more settled legal ground. Web-only businesses have faced a more mixed body of case law across different federal circuits, though the overall trend has still moved toward broader coverage over time rather than narrower.

What compliance actually requires

WCAG 2.1 AA covers a wide range of requirements: sufficient color contrast, keyboard-only navigability, meaningful alt text on images, properly labeled form fields, captions on video content, and a logical heading structure that works with screen readers, among many others. It’s a genuinely broad standard, not a short checklist, which is part of why full compliance takes real work rather than a single fix.

A useful data point on how far the average site still is from this bar: the 2026 WebAIM Million report found that 95.9% of home pages had at least one detectable WCAG 2 failure, with low-contrast text alone present on 83.9% of home pages, the single most common failure type found. Most sites, ADA-covered or not, have real gaps to close.

The same study found an average of 56.1 detectable errors per home page, a figure that’s worth sitting with for a moment. That’s not one or two overlooked details, it’s dozens of individual issues on a typical page, which is a fair indication of why a genuine WCAG 2.1 AA compliance effort takes real, sustained work rather than a quick pass by whoever built the site originally.

Where widgets fit and where they don’t

Overlay widgets, offered by vendors like accessiBe and UserWay, install with a script tag and can address certain surface-level issues quickly, things like resizing text, adjusting contrast, or adding some keyboard navigation support. What they generally can’t do reliably is fix issues rooted in a site’s underlying markup, like a form that isn’t properly labeled in the code or a custom component that doesn’t expose the right ARIA roles. Regulators have taken a skeptical view of overlay-only claims specifically: in 2025 the FTC ordered accessiBe to pay $1,000,000 to settle charges that it made misleading claims about how much of a site accessWidget could automatically fix, along with allegations about paid customer reviews.

That doesn’t mean every vendor in this category operates the same way. AudioEye, for instance, pairs its automated widget with human-in-the-loop manual testing rather than shipping automation alone, an approach more aligned with how a genuine WCAG 2.1 AA program actually needs to work.

What to do if you’ve received a demand letter

ADA website accessibility demand letters and lawsuits are common enough that having a plan matters. The first step is getting an actual WCAG 2.1 AA audit done, ideally one that includes manual testing rather than relying solely on an automated scan, since automated tools reliably catch only a portion of real issues. From there, prioritize fixes based on severity and how many users each issue affects, and loop in an attorney experienced with ADA Title III web claims before responding to any letter, since response strategy has real legal implications beyond the technical fix itself.

It’s worth resisting the urge to respond defensively or dismissively to a demand letter before you’ve actually looked at your site. Many demand letters, whatever their motivation, do point at real issues, and having a documented remediation plan already underway tends to put a business in a much stronger position, whether that plan ultimately factors into settlement discussions or simply closes the underlying gap before it becomes a repeated target.

Publishing an accessibility statement

A public accessibility statement isn’t a legal requirement under the ADA specifically, but it’s become a common and useful practice regardless. A good statement names the standard you’re working toward (typically WCAG 2.1 AA), describes what’s been done so far, and gives visitors a way to report specific issues they encounter. It doesn’t substitute for actual remediation work, and courts generally don’t treat a statement alone as evidence of compliance, but it signals a documented, ongoing effort rather than an unaddressed problem, and it gives you a direct channel for hearing about issues before they turn into a legal complaint.

Building compliance for the long term

A one-time fix doesn’t hold up over time as a site’s content and code keep changing. A durable approach usually combines a real audit against WCAG 2.1 AA, developer-level fixes for structural issues, and some form of ongoing monitoring so new content doesn’t quietly reintroduce old problems. A new product page added without proper alt text, a new form built without labeled fields, or a new promotional banner that fails contrast requirements can each reopen a gap that was previously closed, which is why treating accessibility as a one-time project rather than an ongoing discipline tends to produce compliance that erodes within a year or two.

It’s worth remembering that ADA website compliance isn’t purely a legal exercise, even though legal exposure is often what prompts a business to act. The underlying goal is that people with disabilities, whether that means blindness, low vision, motor impairments, or cognitive differences, can actually use the site to browse, compare, and buy the way any other customer can. A site that technically passes an automated scan but is genuinely difficult for a screen reader user to navigate hasn’t really achieved what the standard is aiming for, even if it would survive a surface-level review. Keeping that underlying goal in view tends to produce better prioritization decisions than treating each WCAG criterion as an isolated checkbox to clear.

Our guide on choosing between a widget and a manual audit goes deeper into how to sequence that work depending on your site’s size and budget.