ADA Website Compliance: What It Actually Means and How to Get There

Title III of the ADA prohibits discrimination by "places of public accommodation." Courts have widely applied this to websites and apps tied to a business serving the public. The catch is that the statute, written in 1990, sets a goal (equal access) without specifying how to achieve it on a website. There is no federal regulation that says "a compliant site must do X, Y, and Z."

In practice, ADA website compliance means your site is usable by people with disabilities: someone who is blind can navigate it with a screen reader, someone who cannot use a mouse can complete every task with a keyboard, someone with low vision can read your text, and someone with a motor impairment can operate your controls. The Department of Justice has stated that businesses have flexibility in how they comply, but that the obligation itself is real and current.

Because the ADA names no technical benchmark, the Web Content Accessibility Guidelines (WCAG), published by the W3C, fill the vacuum. WCAG organizes requirements into three levels: A (minimum), AA (the target for most legal and policy contexts), and AAA (enhanced). Settlement agreements, DOJ guidance, and consent decrees overwhelmingly reference WCAG 2.1 or 2.2 Level AA, which is why it functions as the de-facto US standard even though it is not written into the ADA itself.

WCAG 2.2 is the current version. It builds on 2.1 by adding nine success criteria and retiring one. The additions most likely to affect a typical business site include:

• 2.4.11 Focus Not Obscured (Minimum) (AA) - a focused element must not be entirely hidden behind sticky headers or cookie banners
• 2.5.7 Dragging Movements (AA) - any drag action needs a single-pointer alternative, such as a control you can also tap
• 2.5.8 Target Size (Minimum) (AA) - interactive targets should be at least 24 by 24 CSS pixels (with documented exceptions)
• 3.2.6 Consistent Help (A) and 3.3.7 Redundant Entry (A) - help options stay in a consistent place and forms stop asking for the same information twice
• 3.3.8 Accessible Authentication (Minimum) (AA) - logins cannot force a cognitive test like memorizing or transcribing a code with no alternative

WCAG 2.2 also removed 4.1.1 Parsing, which had become largely redundant with modern browsers and assistive technology. For a fuller breakdown of every criterion and how to test it, see the WCAG reference.

One related point: if you sell into the EU, the European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025, with a baseline of WCAG 2.2 Levels A and AA via the harmonized standard EN 301 549. Targeting WCAG 2.2 AA covers both US ADA expectations and the EAA in one effort.

Most website accessibility actions begin not with a courtroom but with a demand letter from a plaintiff's attorney, often after an automated scan flags barriers on a homepage. The economics favor volume: a single firm may send similar letters to many businesses whose sites share the same defects. Settlement is frequently cheaper than litigation, which is exactly why these claims are filed in such numbers.

The barriers cited are remarkably consistent. The most common are images without alternative text, form fields without programmatic labels, insufficient color contrast, content that cannot be reached or operated by keyboard, and inaccessible menus or modal dialogs. These are also among the cheapest issues to fix before anyone notices them, which is the entire argument for proactive remediation.

An accessibility overlay widget - the floating toolbar that promises instant compliance - does not reliably reduce this risk and has itself become a target of complaints. Real conformance comes from fixing the underlying code, not from a script layered on top.

Assessment works best in two passes. Start with an automated scan to catch the machine-detectable failures, then test the things only a human can judge.

• Run an automated scan with a free checker like AccessScan to surface missing alt text, contrast failures, and unlabeled form controls
• Check color contrast against the thresholds: 4.5:1 for normal text, and 3:1 for large text (at least 18pt, or 14pt bold) and for UI components and graphics
• Unplug your mouse and navigate the entire site by keyboard, confirming a visible focus indicator and a logical tab order
• Test core flows (search, add to cart, checkout, contact form) with a screen reader such as NVDA or VoiceOver
• Work through a structured accessibility checklist so nothing falls through the cracks

Remember that automated tools catch only part of the WCAG picture. The difference between a passing scan and a genuinely usable site is the manual and assistive-technology testing layered on top.

Prioritize by impact. Fix anything that blocks a task outright (an unlabeled checkout button, a keyboard trap in a modal) before cosmetic issues. Then work through the high-frequency categories that drive most complaints.

• Add descriptive alt text to meaningful images and empty alt to decorative ones
• Give every form field a programmatic label and clear, associated error messages
• Ensure full keyboard access with a visible focus indicator on every interactive element
• Fix color contrast to meet the 4.5:1 and 3:1 thresholds
• Use semantic HTML first and add ARIA only where native elements fall short

Once you have made and verified your fixes, document them. A clear accessibility statement describing your conformance level, testing methods, and a way to report problems demonstrates good faith and gives users a route to reach you before they reach a lawyer.

Accessibility is not a one-time project. Every new template, campaign page, or third-party widget can reintroduce barriers, so fold a quick scan and keyboard check into your release process and re-audit periodically.