ADA Website Compliance Checklist 2026

1. Perceivable

All images have descriptive alt text

Every <img> must have an alt attribute that describes its content. Decorative images use alt="". (SC 1.1.1)

Videos have captions

Pre-recorded video content must have synchronised captions. Live video should have captions where possible. (SC 1.2.2, 1.2.4)

Audio has transcripts

Pre-recorded audio-only content (podcasts, voice messages) must have a text transcript. (SC 1.2.1)

Colour contrast meets 4.5:1 for normal text

Normal text (under 18pt / 14pt bold) must have at least a 4.5:1 contrast ratio against its background. (SC 1.4.3)

Colour contrast meets 3:1 for large text

Large text (18pt+ / 14pt+ bold) must have at least a 3:1 contrast ratio. (SC 1.4.3)

Colour is not the only way to convey information

Links, errors, and required fields must not rely on colour alone — use underlines, icons, or text labels as well. (SC 1.4.1)

Text can be resized to 200% without loss of content

Users must be able to zoom to 200% without content being clipped or overlapping. (SC 1.4.4)

Content reflows at 320px width without horizontal scrolling

Responsive layout must work at 320 CSS pixels wide (equivalent to 1280px at 400% zoom). (SC 1.4.10)

Non-text UI components have 3:1 contrast ratio

Form borders, icons, focus indicators must have 3:1 contrast against adjacent colours. (SC 1.4.11)

2. Operable

All functionality is available via keyboard

Every interactive element — links, buttons, forms, menus — must be operable using only the keyboard (Tab, Enter, Space, Arrow keys). (SC 2.1.1)

No keyboard traps

Users must be able to navigate into and out of every component using the keyboard. Modal dialogs must trap focus correctly and release it on close. (SC 2.1.2)

Focus order is logical and predictable

Tab order should follow the visual reading order: left-to-right, top-to-bottom. Do not use tabindex values greater than 0. (SC 2.4.3)

Focus indicators are visible

The keyboard focus indicator (outline) must be clearly visible. Default browser outlines must not be removed without replacement. (SC 2.4.7, 2.4.11)

Skip-to-content link is present

A 'Skip to main content' link should be the first focusable element so keyboard users can bypass repetitive navigation. (SC 2.4.1)

Page titles are descriptive and unique

Each page must have a <title> that describes the page's topic or purpose. (SC 2.4.2)

No content flashes more than 3 times per second

Flashing content can trigger seizures. Avoid animations that flash more than 3 times per second. (SC 2.3.1)

Users can pause, stop, or hide moving content

Carousels, auto-playing videos, and animations must have visible pause/stop controls. (SC 2.2.2)

Touch targets are at least 24×24 CSS pixels

Interactive elements must be large enough to tap accurately. WCAG 2.2 requires 24×24px minimum. (SC 2.5.8)

3. Understandable

Page language is declared

The <html> element must have a lang attribute (e.g., lang="en") so screen readers pronounce content correctly. (SC 3.1.1)

Form inputs have visible labels

Every form field must have a <label> element associated via the for attribute (or wrapped around the input). Placeholder text alone is not sufficient. (SC 3.3.2, 1.3.1)

Error messages identify the field and suggest a fix

When a user makes an error, the message must identify which field has the error and, if possible, suggest how to correct it. (SC 3.3.1, 3.3.3)

Forms do not auto-submit on input change

Changing a form element's value should not automatically submit the form or navigate away without warning. (SC 3.2.2)

Navigation is consistent across pages

Main navigation menus should appear in the same position and order on every page. (SC 3.2.3)

Required fields are clearly indicated

Required fields must be marked with more than just an asterisk — use the word 'required' or the required attribute. (SC 3.3.2)

4. Robust

HTML is valid and well-formed

Elements have complete start/end tags, no duplicate attributes, and unique IDs. Validation errors can confuse assistive technology. (SC 4.1.1)

ARIA roles and attributes are used correctly

If you use ARIA, follow the specification. Incorrect role/aria-* combinations create more barriers than they solve. (SC 4.1.2)

Dynamic content updates are announced

Content that changes without a page reload (toasts, live regions, status messages) must use aria-live or role="status" so screen readers announce it. (SC 4.1.3)

Custom components have accessible names

Every interactive widget (custom dropdowns, sliders, modals) must have an accessible name via aria-label, aria-labelledby, or a visible label. (SC 4.1.2)

5. Legal & Process

Accessibility statement is published

Publish a page describing your accessibility commitment, conformance level, known issues, and contact information for reporting barriers.

Feedback mechanism is available

Provide a way for users to report accessibility issues — email, form, or phone number — and respond within a reasonable timeframe.

Third-party content has been audited

Embedded widgets, iframes, and third-party scripts (chat widgets, payment forms, social embeds) must also meet WCAG requirements.

Regular automated scans are scheduled

Run automated accessibility scans at least monthly. Automated tools catch ~30-40% of WCAG issues and are the first line of defense.

Manual testing with screen readers has been done

Test with at least one screen reader (NVDA/Windows, VoiceOver/Mac, TalkBack/Android) to catch issues automated tools cannot.

Understanding ADA Web Compliance

The Americans with Disabilities Act (ADA) was signed into law in 1990 to prohibit discrimination against people with disabilities in all areas of public life. While the original text did not mention websites, federal courts — starting with the landmark Robles v. Domino's Pizza (2019) — have consistently ruled that websites of public accommodations must be accessible. In 2024, the Department of Justice published a final rule under Title II requiring state and local government websites to meet WCAG 2.1 Level AA — and courts have applied the same standard to private businesses under Title III.

This means that if your business has a physical location open to the public, or if you offer goods and services online, your website is almost certainly covered by the ADA. The technical standard courts reference is WCAG 2.1 Level AA (with WCAG 2.2 as the current recommended version). This checklist covers WCAG 2.2 Level AA, which is a superset of 2.1 AA.

The Lawsuit Landscape

ADA web accessibility lawsuits have grown sharply over the past five years. In 2025, over 8,600 lawsuits were filed in the United States alone — a 12% increase over 2024. The most targeted industries are e-commerce, food service, banking, travel, and healthcare. The average settlement is $25,000–$75,000, with some cases reaching into the hundreds of thousands.

The plaintiffs' bar has become highly sophisticated. Law firms use automated scanning tools to identify non-compliant websites at scale, then file serial demand letters. The economics are straightforward: most businesses settle quickly because litigation costs exceed settlement amounts. Having a demonstrably accessible website — and evidence of ongoing monitoring — is your best legal defence.

What the Law Requires

There is no single ADA standard for private-sector websites. However, courts and the DOJ have coalesced around WCAG 2.1 Level AA as the de facto benchmark. Key requirements include:

All images must have descriptive alternative text
All video content must have synchronised captions
Colour contrast must meet minimum ratios (4.5:1 for normal text, 3:1 for large text)
All functionality must be accessible via keyboard
Forms must have proper labels and error messages
Dynamic content must be announced to screen readers
The site must be navigable and usable with assistive technology

For state and local government websites (Title II), the DOJ's 2024 rule explicitly requires WCAG 2.1 AA, with compliance deadlines based on population size. Private businesses should treat this as the floor, not the ceiling.

Most Common ADA Violations

Based on analysis of thousands of Accesseon scans and the WebAIM Million report, the most frequently cited WCAG violations in ADA lawsuits are:

Low colour contrast (81% of sites) — SC 1.4.3
Missing alt text on images (54% of sites) — SC 1.1.1
Missing form input labels (48% of sites) — SC 1.3.1, 3.3.2
Empty links / empty buttons (44% of sites) — SC 2.4.4, 4.1.2
Missing document language (17% of sites) — SC 3.1.1

These five violations alone account for the vast majority of automated findings. Fixing them is the highest-impact first step toward ADA compliance.

How to Start

The most effective approach to ADA compliance is a three-step process:

Automated scan — Run a free Accesseon scan to identify the most common violations. Automated tools catch approximately 30-40% of WCAG issues, including the top 5 violations listed above.
Manual review — Test your site with a keyboard (Tab through every page) and a screen reader (NVDA on Windows, VoiceOver on Mac). Focus on forms, navigation, and dynamic content like modals and toast notifications.
Ongoing monitoring — Accessibility is not a one-time fix. New content, design changes, and third-party widget updates can introduce regressions. Schedule regular scans and include accessibility in your QA process.

Use the checklist above to track your progress. Check off each item as you verify it on your site. When every box is checked, you have strong evidence of good-faith compliance — the most important factor in defending against an ADA claim.