ADA Title III Website Compliance Checklist

The legal basis: ADA Title III and websites

Title III of the Americans with Disabilities Act prohibits discrimination on the basis of disability in places of public accommodation. The ADA was enacted in 1990, before the commercial web existed — which has produced decades of litigation over whether websites qualify as “places of public accommodation.”

The current legal landscape has largely settled that question in favor of inclusion. The majority of federal courts that have addressed the issue have held that websites operated by businesses open to the public are covered by Title III. The Department of Justice (DOJ) released formal guidance in March 2022 confirming that the ADA applies to websites. In April 2024, the DOJ published a final rule under Title II (covering state and local governments) explicitly adopting WCAG 2.1 Level AA — establishing a strong signal for what Title III will eventually codify.

The practical result: if you operate a website through which customers access goods, services, or information, ADA Title III applies to that website.

What “accessible” means under ADA

The ADA does not define a specific technical standard for website accessibility. Courts and the DOJ have consistently treated compliance with the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA as the benchmark for determining whether a website meets the ADA’s non-discrimination requirement. WCAG 2.1 AA is the standard used in nearly all DOJ settlement agreements and most court-supervised compliance plans.

The checklist below maps the most critical WCAG 2.1 AA success criteria to practical compliance obligations.

ADA Title III website compliance checklist

1. Text alternatives for non-text content

Every meaningful image has an alt attribute that conveys its purpose
Decorative images have an empty alt="" so screen readers skip them
Icons used as buttons or links have accessible names (via aria-label or visible text)
Charts and infographics have text descriptions or data tables as alternatives
CAPTCHA provides an audio alternative alongside the visual challenge

Why it matters: Screen reader users receive no information about an image without alt text. A checkout button labeled only with an icon and no accessible name is effectively invisible to a screen reader user.

2. Captions and transcripts for media

Pre-recorded videos have synchronized closed captions
Live video streams have real-time captions
Pre-recorded audio-only content (podcasts) has a text transcript
Pre-recorded videos with important audio have a transcript available
Auto-generated captions are reviewed and corrected before publishing

Why it matters: Captions are the primary means by which deaf and hard-of-hearing users access video content. Inaccurate auto-generated captions do not satisfy the requirement.

3. Color and visual design

Information is never conveyed by color alone (e.g., required fields are marked with text or an icon, not only a red border)
Normal text (under 18pt / 14pt bold) meets a contrast ratio of at least 4.5:1 against its background
Large text (18pt+ or 14pt+ bold) meets a contrast ratio of at least 3:1
UI components (buttons, inputs, focus indicators) have at least 3:1 contrast against adjacent colors
Error states communicate the error in text, not only through color change

Why it matters: Approximately 8% of men and 0.5% of women have some form of color vision deficiency. Relying on color alone excludes a significant portion of your users.

4. Keyboard accessibility

All interactive elements (links, buttons, forms, menus, modals, date pickers) are reachable and operable using only a keyboard
Tab order follows a logical, predictable sequence
No keyboard traps — users can navigate into and out of every component using standard keys
Custom widgets (dropdowns, sliders, dialogs) implement expected keyboard interaction patterns
A “skip to main content” link is the first focusable element on every page

Why it matters: Users with motor disabilities, many of whom rely on keyboard navigation or switch-access devices, cannot use a mouse. A site that requires mouse interaction for core functions is inaccessible to them.

5. Focus visibility

Keyboard focus is always visible — a clear focus indicator (outline, highlight, underline) appears on the active element
The focus indicator is not suppressed with outline: none or outline: 0 without a replacement
The focus indicator has sufficient contrast against the surrounding content

Why it matters: Without a visible focus indicator, keyboard users cannot tell where they are on the page — equivalent to browsing without a cursor.

6. No seizure-triggering content

No content flashes more than three times per second
Animations that cannot be disabled do not span large portions of the viewport at high frequency
Parallax effects and auto-playing animations can be paused or reduced via prefers-reduced-motion media query

Why it matters: Photosensitive epilepsy affects a significant portion of the population. A single flashing advertisement can trigger a seizure.

7. Enough time to complete tasks

Session timeouts warn users before expiring and give them a way to extend the session
Auto-updating content (news tickers, live scores, rotating banners) can be paused, stopped, or hidden
No time limits are imposed on critical tasks (checkout, form submission) without an adequate extension mechanism

Why it matters: Users with cognitive disabilities, motor impairments, or who use assistive technology often need more time to complete tasks. Abrupt timeouts can result in lost progress.

Every page has a unique, descriptive <title> element
Navigation menus are consistent in structure and location across pages
The current page location is indicated in the navigation (active state)
Breadcrumb trails are present on deep pages
Multiple ways to find content exist (search, site map, or navigation)
Headings are structured logically (h1 → h2 → h3) and describe section content accurately

Why it matters: Screen reader users navigate by headings, landmarks, and page titles. Poorly structured headings make a page unintelligible to someone navigating with a screen reader.

9. Form accessibility

Every form input has a visible <label> element programmatically associated with it
Required fields are identified in text (not only by an asterisk without explanation)
Error messages identify which field contains the error and describe how to fix it
Error messages are announced to screen reader users (via aria-live or focus management)
Autocomplete attributes are present on common inputs (name, email, address, credit card)
Form submission does not time out silently

Why it matters: Forms are how users transact with your service — booking, purchasing, registering, contacting. An inaccessible checkout is the digital equivalent of a store with no ramp.

10. Links and buttons

Every link has a descriptive accessible name — “Read more” alone is not sufficient; “Read more about [topic]” is
Links and buttons are distinguishable from surrounding text without relying solely on color
Buttons that trigger actions are marked as <button> elements, not styled <div> or <span> elements
Links that open in a new tab or trigger a download communicate this to the user

Why it matters: Screen reader users often browse by listing all links on a page. A list of “click here” and “read more” links provides no navigational value.

11. Language and readability

The primary language of the page is set in the lang attribute on the <html> element (e.g., lang="en")
Sections in a different language are marked with a lang attribute on the containing element
Abbreviations are expanded on first use or via <abbr title="..."> where helpful

Why it matters: Screen readers use the language attribute to select the correct pronunciation engine. Without it, English text read by a German-language engine is nearly unintelligible.

12. Consistent, predictable behavior

Receiving focus does not automatically trigger a context change (e.g., a form does not submit when a field gains focus)
Changing a form input does not trigger unexpected navigation or modal dialogs
Components with the same function across pages are labeled consistently

Why it matters: Unpredictable behavior is disorienting for all users, but particularly for those with cognitive disabilities or who rely on screen readers.

13. PDFs and documents

PDFs available for download are tagged for structure (headings, lists, reading order)
PDF form fields are labeled
Scanned PDFs (image-only) are OCR-processed and tagged
Word, Excel, and PowerPoint files use built-in accessibility features (heading styles, alt text, sheet names)

Why it matters: Courts and the DOJ have consistently treated downloadable documents as part of a website’s accessible content. An inaccessible PDF in an otherwise accessible checkout is still a barrier.

14. Mobile accessibility

All functionality is available in both portrait and landscape orientations
Touch targets (buttons, links) are at least 44×44 CSS pixels
Content does not require horizontal scrolling at standard viewports
The site does not disable user scaling via maximum-scale or user-scalable=no in the viewport meta tag

Why it matters: Many users with disabilities use mobile devices as their primary or sole means of accessing the web. Mobile barriers exclude them as effectively as desktop barriers.

15. Accessibility statement

An accessibility statement is published and linked from the site footer
The statement identifies the standard the site targets (WCAG 2.1 AA)
The statement includes a contact mechanism for users to report barriers
The contact mechanism is itself accessible

Why it matters: An accessibility statement demonstrates good faith and gives users a path to resolution before they seek legal remedies. It is also required under several state laws and is expected practice under DOJ guidance.

Enforcement and litigation risk

ADA Title III does not require plaintiffs to prove intentional discrimination. If a barrier exists, and if it prevented a person with a disability from accessing goods or services, a claim can proceed. Remedies under Title III do not include damages (unlike Section 504), but they do include injunctive relief and attorneys’ fees — which are often the primary driver of serial litigation.

The volume of ADA website accessibility lawsuits in the United States has risen sharply in recent years, with thousands filed annually. Small and mid-sized businesses are frequent targets because they are perceived as less likely to have invested in compliance.

If you have received an ADA demand letter, do not ignore it. Engage legal counsel promptly and commission an accessibility audit so you have an accurate picture of your site’s conformance.

Maintaining compliance over time

A one-time audit and remediation is not sufficient. Every new page, feature, or third-party integration can introduce new barriers. Organizations with the lowest litigation risk maintain compliance continuously:

Automated scanning embedded in the development workflow catches detectable issues before they reach production. Our CI/CD accessibility integration service makes this part of every build.
Scheduled manual audits surface the issues automated tools cannot detect — screen reader interaction, cognitive complexity, keyboard traps.
Accessibility training for developers and content authors prevents barriers from being introduced in the first place.
User feedback mechanisms give people with disabilities a direct channel to report barriers before they become legal issues.

A free automated scan is the fastest way to identify your site’s most visible WCAG failures. For a complete picture that maps to your ADA exposure, contact our team to discuss a full audit.