ADA compliance for websites means your site must be usable by people with disabilities, including those who rely on screen readers, keyboard navigation, or high-contrast displays. Courts and the DOJ reference WCAG 2.1 Level AA as the practical benchmark. Automated accessibility testing can catch roughly 30 to 40 percent of issues. The remainder requires human review to confirm real-world usability.
Your site looks great. Clean design, fast load times, a mobile layout that holds together. And then the demand letter arrives.
That’s not a hypothetical. Thousands of U.S. businesses receive ADA-related demand letters every year, most of them from site owners who assumed visual polish meant legal protection. It doesn’t. ADA compliance for websites is a code-level obligation, not a design one, and the gap between what most sites deliver and what the law actually expects is wider than most people realize.
This article breaks down what compliance actually means in practice, what automated accessibility testing can and cannot do for you, and why the distinction between a scan and a real audit matters more than most vendors will tell you.
What Is ADA Compliance for Websites and Who Does It Apply To?
The Americans with Disabilities Act was signed into law in 1990. It didn’t mention websites, because the web barely existed. What it did establish was a broad prohibition on discrimination against people with disabilities in places of public accommodation.
Here’s where it gets interesting. Courts began applying that reasoning to websites in the late 2010s, and by the mid-2020s, federal courts had largely settled the question: if your business has a public-facing website, it is subject to ADA Title III obligations. The Department of Justice has consistently backed this interpretation in briefs, settlement agreements, and formal guidance to lawmakers.
The practical standard courts use is WCAG 2.1 Level AA. That’s the Web Content Accessibility Guidelines published by the W3C’s Web Accessibility Initiative. The DOJ has not codified WCAG into federal regulation for private businesses, but it has referenced these guidelines repeatedly as the relevant technical benchmark. In practice, that makes WCAG 2.1 AA the closest thing to an official compliance target that exists.
Who Is Actually Covered Under ADA Title III?
Title III applies to “places of public accommodation.” That category is broad. Hotels, restaurants, retail stores, professional services, financial institutions, healthcare providers, and e-commerce platforms have all been named in ADA website lawsuits. Small business size does not exempt you. The number of employees is not a factor.
The only meaningful exception is for businesses with no public-facing commercial presence whatsoever, which describes very few operational websites. If your site accepts orders, schedules appointments, or provides information to potential customers, you are almost certainly covered.
What Does WCAG 2.1 Level AA Actually Require?
WCAG is built around four core principles, often called POUR: Perceivable, Operable, Understandable, and Robust. Under those principles sit 13 guidelines and 78 individual success criteria at Level AA.
The most frequently cited failures in ADA litigation include:
- Missing or meaningless alt text on images
- Form fields without programmatically associated labels
- Insufficient color contrast ratios (the minimum is 4.5:1 for body text)
- Interactive elements that can’t be reached or activated by keyboard alone
- Videos without captions or audio descriptions
- Dynamic content that doesn’t properly notify screen readers of state changes
That last one catches a lot of developers off guard. A modal, a dropdown menu, an accordion that expands, a live chat widget: all of these require ARIA (Accessible Rich Internet Applications) attributes to communicate state changes to assistive technologies like JAWS, NVDA, or VoiceOver. A site can look and function perfectly for sighted users while being functionally unusable for someone relying on a screen reader.
Why Overlay Tools Don’t Solve the Problem
This is probably the most important section of this article, and the one most vendors would prefer you skip.
Accessibility overlay products are JavaScript widgets that sit on top of your existing code and claim to fix accessibility issues in real time. They’re popular because they’re cheap, fast to deploy, and come with compliance certificates that look official. The problem is that they don’t work, and the legal record now proves it.
U.S. courts have consistently rejected overlay tools as insufficient remediation in ADA cases. The National Federation of the Blind officially opposes overlay products and has published detailed statements explaining why they fail users with disabilities. In 2025, the FTC took enforcement action against a major overlay provider for deceptive compliance claims. These aren’t fringe positions. They’re the legal and advocacy mainstream.
The technical reason overlays fail is structural. An overlay can intercept some rendering issues and add some attributes after the fact. But it can’t fix keyboard flow that was never built correctly. It can’t create meaningful alt text for images without semantic context. It can’t restructure a form that was built with div tags instead of proper HTML form elements. And it can’t fix any of these things before they’re served to the user’s browser, which means screen reader users encounter the broken version first.
Automated accessibility testing through an overlay detects only 20 to 30 percent of WCAG violations. The remaining issues persist in your underlying code and continue to generate legal exposure, regardless of what the compliance badge on your homepage says.
What Automated Accessibility Testing Can Legitimately Do
None of this means automated tools are worthless. They’re not. They’re just not sufficient on their own, and the distinction matters.
A good automated scan runs against your site’s HTML, CSS, and JavaScript and checks for machine-detectable WCAG failures: missing labels, contrast ratios below threshold, images with empty alt attributes, form elements without associated text, duplicate IDs in the DOM. These are real issues. Catching them is genuinely useful. Fixing them reduces your risk profile immediately.
The honest number is that automated tools reliably catch about 30 to 40 percent of WCAG issues. That’s not a failure of the technology. It reflects a fundamental limit: some accessibility failures can only be evaluated with human judgment. Whether an image description is actually meaningful, whether a focus order makes logical sense as a navigation experience, whether a form validation message is communicated in a way a screen reader user can act on: these require someone to actually use the site with assistive technology.
That sounds obvious. Most people still don’t do it.
What a Scan Can Catch Immediately
Start with a URL scan and you’ll typically surface:
- Images with missing or empty alt attributes
- Color contrast failures across text and backgrounds
- Form inputs without visible, programmatically associated labels
- Missing page titles or skip navigation links
- Heading hierarchy problems (H3 used before H2, headings skipped entirely)
- PDF files linked from the page that haven’t been tagged for accessibility
That’s a meaningful list. For many sites, fixing those issues alone removes the most common triggers for demand letters. But it won’t produce full WCAG 2.1 AA conformance, and it won’t stand up as sufficient remediation if litigation occurs.
Where Human Review Becomes Non-Negotiable
Keyboard navigation testing requires a human. You press Tab to move through every interactive element on the page and verify that focus is visible, the order is logical, and every action available with a mouse is also achievable with a keyboard. No automated tool can evaluate whether that experience is actually usable.
Screen reader testing requires someone to run JAWS or NVDA and navigate your site the way a blind user would. The difference between a list that reads correctly and one that reads as a stream of disconnected text is a human judgment call. So is the difference between a button labeled “Submit” and one labeled “Click here.”
How to Actually Achieve ADA Compliance for Websites
The path looks like this, in order:
Step 1: Run an automated scan to establish a baseline.
You need to know where you start before you can measure progress. A scan against your homepage and key landing pages will surface the machine-detectable issues and give you a risk score. Do this before anything else.
Step 2: Fix the machine-detectable issues first.
Alt text, labels, contrast, heading structure, skip navigation: these are fixable in most codebases within days. Fixing them eliminates the lowest-hanging litigation risk and brings your baseline score up before the human audit phase begins.
Step 3: Commission a human-verified WCAG audit.
This is where an expert manually tests your site using actual assistive technologies, keyboard navigation, and screen reader software. The output is a detailed report mapped to WCAG 2.1 AA criteria, with specific remediation guidance for each failure. Not vague recommendations. Exact locations in the code with clear instructions for how to fix each issue.
Step 4: Remediate and verify. Fixes need to be tested after implementation.
A closed issue isn’t closed until a human confirms the remediated element actually works as expected in an assistive technology environment. This step gets skipped constantly, which is why sites that claim to be accessible often aren’t.
Step 5: Monitor ongoing.
Websites change. New pages get published. New components get added. A feature that was accessible last quarter might break accessibility today if a developer pushed an update without checking it. Ongoing monitoring, either through scheduled automated scans or periodic human reviews, is the only way to maintain compliance over time.
Frequently Asked Questions
Q: What is ADA compliance for websites?
A: ADA compliance for websites means your site must be accessible to users with disabilities under the Americans with Disabilities Act. Courts apply this to commercial websites and reference WCAG 2.1 Level AA as the practical technical standard. It covers everything from screen reader compatibility to keyboard navigation to color contrast.
Q: Does ADA compliance apply to small business websites?
A: Yes. ADA Title III covers businesses classified as places of public accommodation regardless of size or number of employees. If your site accepts customers or provides services to the public, it falls within the scope of the law.
Q: What is automated accessibility testing?
A: Automated accessibility testing is the process of running software tools against your website’s code to identify WCAG violations that machines can detect reliably. These include missing form labels, contrast failures, missing alt text, and structural errors. Automated tools catch roughly 30 to 40 percent of total WCAG issues.
Q: Is a WCAG compliance badge enough to protect against ADA lawsuits?
A: No. Badges issued by overlay tools or automated-only platforms have been specifically rejected as insufficient remediation in U.S. court cases. Legal protection comes from demonstrated conformance with WCAG standards, not from a badge.
Q: What’s the difference between an accessibility scan and an accessibility audit?
A: A scan is an automated process that checks your code against machine-detectable WCAG criteria. It takes seconds and surfaces about a third of possible issues. An audit combines automated scanning with manual human testing using assistive technologies, covering the full range of WCAG success criteria and providing documented evidence of conformance.
Q: How often should a website be audited for ADA compliance?
A: A full human-verified audit should be conducted at least annually and after any significant redesign or feature release. Automated scans should run continuously or on a weekly schedule to catch new issues introduced by content updates and code changes.
Leave feedback about this