ADA & WCAG: web accessibility compliance in the US

Web accessibility means building websites that people with disabilities can use. That includes people who are blind or have low vision, people who are deaf or hard of hearing, people with motor impairments, and people with cognitive disabilities.

In the United States, the Americans with Disabilities Act (ADA) has been interpreted to apply to websites. The practical standard for measuring accessibility is the Web Content Accessibility Guidelines (WCAG), published by the World Wide Web Consortium (W3C).

The ADA and websites

The Americans with Disabilities Act was signed in 1990. It prohibits discrimination against people with disabilities in public accommodations, employment, government services, and more.

Courts and the Department of Justice have consistently interpreted "public accommodations" to include websites, particularly for businesses that also operate physical locations — but increasingly for online-only businesses too. There is no single federal regulation that spells out exactly what a website must do, but the DOJ has stated that WCAG 2.1 Level AA is the appropriate standard.

ADA-related website accessibility lawsuits have increased significantly over the past several years. Retailers, restaurants, financial services, and healthcare providers are among the most common targets — but businesses of all sizes have received demand letters.

What WCAG is

WCAG (Web Content Accessibility Guidelines) is a set of technical recommendations from the W3C (the international body that sets web standards). The current widely referenced version is WCAG 2.1. WCAG 2.2 was published in 2023 with additional criteria.

WCAG guidelines are organized into three conformance levels:

WCAG 2.1 Level AA is the target most legal standards, government guidance, and accessibility best practices point to.

The four principles of WCAG

WCAG is built on four principles, often abbreviated as POUR:

Perceivable

Information must be presentable in ways all users can perceive. Examples:

• Images have descriptive alt text so screen readers can describe them
• Videos have captions
• Text has sufficient color contrast against its background

Operable

Users must be able to navigate and operate the interface. Examples:

• Every function is reachable using a keyboard alone (no mouse required)
• There is no content that flashes more than three times per second
• Pages have descriptive titles and clear heading structure

Understandable

Information and UI must be understandable. Examples:

• The page language is identified in the code
• Error messages clearly describe what went wrong and how to fix it
• Navigation is consistent across pages

Robust

Content must work with current and future assistive technologies. Examples:

• HTML is written correctly so screen readers and other tools can parse it
• Custom interactive components follow ARIA (Accessible Rich Internet Applications) standards

Who this applies to

What we do to help

Accessibility is built into our design and development process, not added as an afterthought.

In design:

• We ensure color palettes meet WCAG AA contrast ratios (at minimum 4.5:1 for body text)
• We design clear focus states so keyboard users can see where they are on the page
• We use readable font sizes and adequate line spacing

In development:

• We use semantic HTML (proper headings, lists, landmarks) so assistive technologies work correctly
• Every image gets meaningful alt text, or is marked as decorative if appropriate
• Forms include clear labels and helpful error messages
• We test keyboard navigation on every page before launch

In testing:

• We run automated accessibility scans using tools like Axe or Lighthouse
• We review results and fix flagged issues before launch
• We include accessibility as part of our ongoing care plan reviews

Common pitfalls

• Relying on an "accessibility overlay" widget. These third-party scripts claim to fix accessibility problems automatically. They do not. They can actually introduce new barriers and have been the subject of lawsuits themselves. We do not install overlay widgets.
• Alt text that isn't helpful. "image001.jpg" or "photo" doesn't help someone who can't see the image. Alt text should describe what the image shows and why it's there.
• Forms without labels. A text box with placeholder text only is not accessible. Every form field needs a proper label.
• Low color contrast. Light gray text on white backgrounds may look elegant but fails accessibility standards and is hard to read for many people.
• No keyboard access. If any part of your site requires a mouse — dropdown menus, modals, sliders — keyboard users and screen reader users may be locked out.
• PDFs that aren't tagged. PDFs need to be properly tagged to be readable by screen readers. See our guide on PDFs and documents.

Common questions

Related guides

• Web accessibility basics
• Alt text explained
• Accessible content checklist
• Color contrast & readability
• Accessibility maintenance
• PDFs & documents on your site

Learn more

• ADA.gov — Americans with Disabilities Act official site
• W3C Web Accessibility Initiative — WCAG overview
• W3C — WCAG 2.1 Quick Reference
• WebAIM — practical web accessibility resources