ADA Website Compliance (US): What You Need to Know

If you sell to customers in the United States, you've probably heard that your website needs to be "ADA compliant." It's a real concern — but the details are widely misunderstood. This guide explains, in plain terms, how the Americans with Disabilities Act (ADA) relates to websites, what standard you're actually measured against, and what to do about it. It is general information, not legal advice.

Does the ADA apply to websites?

The ADA, passed in 1990, prohibits discrimination on the basis of disability. Title III covers "places of public accommodation" — businesses open to the public. The Act predates the modern web, so it doesn't mention websites by name. Over time, the U.S. Department of Justice has taken the position that the ADA's accessibility requirements extend to the websites of businesses, and many courts have treated inaccessible websites as a Title III issue. Web-accessibility complaints and lawsuits have become common.

The practical takeaway: if your business serves the public in the US, you should treat your website as in scope, rather than assume it's exempt.

Is there an official ADA technical standard for websites?

This is the part that surprises people: for most private businesses there has not been a single, ADA-specific technical regulation that spells out exactly what a website must do. Instead, the Web Content Accessibility Guidelines (WCAG) — published by the W3C — have become the de facto benchmark. The DOJ has repeatedly pointed to WCAG, and settlements and court decisions commonly require conformance to WCAG Level AA. (US public-sector and government contexts have their own rules, such as Section 508, which is itself aligned with WCAG.)

So while you won't find a law that says "your site must do X, Y, Z," the working answer the market and courts use is: conform to WCAG, at Level AA.

What "compliant" means in practice

Target WCAG 2.1 / 2.2 Level AA. That covers the things that matter most: text that has sufficient contrast, images with meaningful alternative text, forms with proper labels, content operable by keyboard, a logical reading and focus order, captions for media, and pages that work when zoomed. Building and testing to AA is the recognized way to show you took accessibility seriously. For how to actually check, see is my website WCAG 2.2 AA compliant?

How to reduce your risk

The durable approach is the same one that genuinely helps disabled users:

Audit. Run an automated scan to clear machine-detectable failures, then do manual testing (keyboard, screen reader, zoom, forms, media) for the rest.
Fix at the source. Repair the actual HTML, ARIA, and content — real alt text, real labels, real focus management — not a runtime "overlay" patch. (Overlays are widely criticised and can increase risk rather than reduce it.)
Document. Keep a record of what you tested, found, fixed, and have outstanding. Publish an accessibility statement with a way for people to report problems.
Monitor. Accessibility decays as sites change. Re-test after each significant release.

A word on overlays and "instant compliance"

Be cautious of any product promising guaranteed ADA compliance from a single line of JavaScript. Buying a widget does not make a site immune to complaints, and the accessibility community broadly advises against overlays as a compliance solution. Real conformance comes from fixing your content.

Start with a free scan

The fastest way to begin is to see where you stand today. Scan your site free with WCAGwise to find the machine-detectable issues and exactly where each one is in your code. When you need to evidence the work across your whole site, WCAGwise Pro is coming. Remember: this is an audit aid, not a legal guarantee of compliance — for high-risk situations, pair it with manual testing and qualified legal advice.

ADA website compliance (US): what you need to know