ADA Website Compliance Checklist: 36 WCAG 2.1 AA Checks (2026)

An ADA website compliance checklist is a list of the WCAG 2.1 Level AA checks a site should pass so that disabled people can use it. For state and local governments, WCAG 2.1 AA is a legal requirement under the Department of Justice's 2024 Title II rule. For private businesses under Title III there is no such rule: WCAG 2.1 AA is the benchmark courts and the Department's guidance point to. The 36 checks below cover all 50 Level A and AA success criteria, grouped by media, keyboard, structure, color, forms, zoom and code.

We build and run an accessibility scanner, and the most common thing we see is a team that believes its site is accessible because it looks clean and modern. Accessibility is about whether a site works with a screen reader, a keyboard or a magnifier, and that is invisible until you test for it. On 304 agency front pages we scanned in September and October 2026, at least 303 had an accessibility finding.

Which ADA rules apply to your website?

The ADA's text contains no technical detail about websites. Which rule applies, and how firmly, depends on who you are.

The April 2024 rule covers Title II only. It does not apply to private businesses, and a page that says it does is wrong. For Title III, the Department's March 2022 guidance says businesses have flexibility in how they comply and names WCAG and the Section 508 standards as helpful guidance. That is guidance, not a regulation. In practice, demand letters and settlements commonly measure sites against WCAG 2.1 AA, which makes it the sensible target for private-sector website ADA compliance requirements too. [VERIFY: if a sentence about court practice is kept, support it with a primary source such as a named decision or a DOJ settlement that cites WCAG 2.1 AA.]

Public entities should read our guide to ADA Title II website compliance for the dates, exceptions and vendor rules. [VERIFY: that link resolves only once the Title II guide is published.] For how the ADA, Section 508 and state laws fit together, see which accessibility standard applies.

The ADA website compliance checklist at a glance

Each row is one check in plain English, with the WCAG 2.1 success criteria it covers. Together the 36 rows cover all 50 Level A and AA criteria (30 at A, 20 at AA).

This checklist is general information, not legal advice.

Two notes. Criterion 4.1.1 Parsing was removed in WCAG 2.2 as obsolete, but it is still part of WCAG 2.1, the version the Title II rule names. And a scan can test row 13 almost completely and the presence half of rows 25 and 32, flag likely problems on rows 1, 6, 20, 27 and 34 for a person to confirm, and cannot judge rows such as 3, 4 or 26 at all. The section on which checks need a person covers that split.

To check the scan-friendly rows on your own site, you can run a free automated scan with Sitejar.

The checklist in detail

Text alternatives and media

Every meaningful image needs a text alternative a screen reader can read aloud. Good alt text is specific but concise: "woman typing on a laptop in an office" tells the story, while "image123.jpg" tells the user nothing. Decorative images should have empty alt text so the screen reader skips them. Media needs captions, transcripts, and audio description where the picture carries information the soundtrack does not.

• Meaningful images have accurate alt text; decorative ones have alt="" (1.1.1)
• Audio-only content has a transcript (1.2.1)
• Pre-recorded video has accurate captions, not just automatic ones left unedited (1.2.2)
• Video has audio description where visuals carry meaning (1.2.3, 1.2.5); live video has captions (1.2.4)
• Audio that plays on its own for more than three seconds can be paused or muted (1.4.2)
• Nothing flashes more than three times a second (2.3.1)

How to test it in 2 minutes: turn on your browser's image-off view or a screen reader and listen to a key page. Then play your main video with the sound off and read the captions.

Keyboard and focus

Many people navigate with a keyboard alone, and this is where a large share of real barriers live. Every link, button and field must be reachable in a logical order and operable with Tab, Enter, Space and the arrow keys, with no traps.

• Every function works with a keyboard, with no keyboard traps (2.1.1, 2.1.2)
• Single-character shortcuts can be turned off or remapped (2.1.4)
• Time limits can be extended, and carousels or tickers can be paused (2.2.1, 2.2.2)
• A skip link or landmarks let users jump past repeated navigation (2.4.1)
• Focus moves in a logical order, especially in dialogs and menus (2.4.3)
• The focus indicator is always visible (2.4.7)

How to test it in 2 minutes: put your mouse aside and use your site with Tab, Shift+Tab, Enter and the arrow keys. Open a menu and a dialog, and complete a form. If you lose track of focus or get stuck, that feature is broken for keyboard users.

Structure, headings and semantic HTML

Headings are how screen reader users find their way around a page, so they must form a logical outline rather than be chosen for visual size. A real button element comes with keyboard support and the right announcement for free; a styled div gets neither. Small code-quality problems turn into accessibility failures here, as we explore in small code quality issues quietly break accessibility.

• Headings, lists, tables and form labels are real markup (1.3.1)
• The code order matches the visual reading order (1.3.2)
• Instructions do not depend on "the round button" or "the box on the right" alone (1.3.3)
• Each page has a unique, descriptive title (2.4.2)
• Link text makes sense, so no bare "click here" (2.4.4)
• Pages can be found more than one way, and headings and labels describe their content (2.4.5, 2.4.6)

How to test it in 2 minutes: view the heading outline with a browser extension or your screen reader's headings list. It should read like a table of contents with no skipped levels.

Color and contrast

The WCAG 2.1 AA contrast threshold is 4.5:1 for normal text and 3:1 for large text. Low contrast is the most common failure we find: it was on 82% of the 304 agency front pages in our benchmark, and WebAIM found it on 83.9% of the top million home pages in 2026. Never rely on color alone: an error field that only turns red tells a color-blind user nothing. Our guide to fixing low color contrast covers the ratios and a step-by-step fix.

• Color is never the only signal, so errors, links and chart data also use text, underline or pattern (1.4.1)
• Body text meets 4.5:1, and large text meets 3:1 (1.4.3)
• Input borders, icons, focus rings and meaningful graphics meet 3:1 (1.4.11)

How to test it in 2 minutes: run a contrast checker on your body text, buttons and placeholder text, then view the page in grayscale and check that no information disappears.

Forms and errors

A form a user cannot complete is a customer you cannot serve. Every field needs a visible label tied to it in code, not a placeholder that disappears when typing starts. When something goes wrong, name the field and say how to fix it: "Your ZIP code should be five digits", not "invalid entry".

• Every field has a visible, programmatically associated label (3.3.2)
• Name, email, address and payment fields use autocomplete (1.3.5)
• Errors are identified in text, next to the field (3.3.1)
• Error messages suggest a fix where one is known (3.3.3)
• Legal, financial and data-changing submissions can be reviewed, corrected or reversed (3.3.4)
• Success and error messages are announced by screen readers without moving focus (4.1.3)

How to test it in 2 minutes: submit your main form empty with a screen reader running. You should hear which fields failed and why.

Zoom, reflow and readable text

Typical checklists get this subtly wrong: WCAG sets no minimum font size in pixels. What WCAG 2.1 AA requires is that text can be resized to 200% without loss of content or function (1.4.4), and that content reflows into a single column at a width of 320 CSS pixels without sideways scrolling (1.4.10). Use relative units such as rem so the layout scales. Sixteen pixels for body text is a sensible baseline, as Section508.gov's typography guidance discusses, not a legal line.

• Content works in both portrait and landscape (1.3.4)
• Text resizes to 200% without clipping or overlap (1.4.4)
• Text is real text, not an image of text (1.4.5)
• The page reflows at 320 CSS pixels wide (1.4.10)
• The layout survives increased letter, word and line spacing (1.4.12)
• Tooltips and hover menus can be dismissed and do not vanish under the pointer (1.4.13)

How to test it in 2 minutes: zoom the browser to 400% on a desktop window 1280 pixels wide. Nothing should be cut off, and you should only need to scroll vertically.

Code-level robustness: ARIA, names and roles

Custom components fail most here: menus, tabs, carousels, date pickers and modals built from generic elements. AI-generated code tends to add debt too, as we describe in AI-generated code and the accessibility debt nobody is auditing. Prefer native HTML elements, and use ARIA only to fill a real gap.

• Swipe and multi-finger gestures have single-tap alternatives, and actions fire on release (2.5.1, 2.5.2)
• The visible label of a control is part of its accessible name (2.5.3)
• Shake or tilt actions have a button alternative and can be turned off (2.5.4)
• The page language is set, and language changes are marked (3.1.1, 3.1.2)
• Focusing or changing a control does not trigger an unexpected page change, and navigation is consistent (3.2.1 to 3.2.4)
• Markup has no duplicate IDs or broken nesting, and custom controls expose name, role, value and state (4.1.1, 4.1.2)

How to test it in 2 minutes: open your browser's accessibility inspector on a custom menu or tab set. Every control should show a sensible name and role, and its expanded or selected state should change when you use it.

What fails most often: data from 304 websites

Sitejar scanned the front pages of 304 web agency sites between 16 September and 23 October 2026, one read-only scan per site. Agencies build websites for a living. The WebAIM Million figures (February 2026, top one million home pages) use a different tool and method, so compare direction rather than exact values.

Each share carries a 95% interval of roughly plus or minus five points. The full method, intervals and the remaining findings are in our benchmark of 304 agency front pages, and there is more context in our web accessibility statistics for 2026.

Most failures sit in rows 13, 27, 34 and 1, usually in a shared template or design token. Fix it once and the finding disappears from every page that uses it.

A fast ADA checklist for developers

A compressed pass you can run on a page in one sitting. Work in order, because the early steps surface the highest-impact issues.

1. Tab through the whole page with no mouse, and confirm you can reach and operate everything, with a visible focus indicator at every stop and no traps.
2. Run an automated scan to catch the high-volume, machine-detectable issues at once: missing alt text, low contrast, missing form labels, unnamed links and invalid ARIA. You can run a free automated scan with Sitejar, which maps each finding to the WCAG criterion it fails, or use any comparable tool.
3. Check the heading order in the document outline, and confirm it makes sense with no skipped levels and exactly one h1.
4. Zoom to 200%, then to 400% on a 1280-pixel window, and confirm nothing is cut off, overlapping or forcing sideways scrolling.
5. Test custom widgets (menus, modals, carousels, tabs and date pickers) with a screen reader such as NVDA or VoiceOver, since this is where automated tools miss the most.
6. Review color: confirm no meaning is carried by color alone, then verify text contrast reaches 4.5:1 and control borders reach 3:1.

That pass will not certify a site, because no quick check can, but it tells you honestly whether you have a small cleanup or a bigger project.

Which checks need a person, not a tool?

Deque's own audit data found that automated axe-core rules caught 57.38% of issues by volume, but found automated issues for only 16 of the 50 WCAG 2.1 AA success criteria. Both are true: automation catches the common failures well and cannot judge meaning.

Checks that need a person:

• Whether alt text actually describes the image, rather than merely existing
• Whether captions and transcripts are accurate and complete
• Whether focus order is logical in dialogs, menus and multi-step flows
• Whether error messages are clear and suggest a real fix
• Whether link text makes sense in context
• A screen reader pass through each key journey: sign-up, checkout, contact and account

So a perfect automated score does not mean a site is accessible. We explain why a Lighthouse score of 100 is not compliance, and what an accessibility audit proves compared with a statement.

Build a testing process, not a one-time audit

Compliance is a state you maintain, not a milestone. Every new page or feature can reintroduce a barrier, so build checking into how you ship.

• Scheduled re-scans, so regressions show up within days rather than in a demand letter
• Release checks with keyboard and screen reader on new interactive components
• Content author training on headings, alt text, link text and documents
• A remediation log of what was found and when it was fixed
• Testing with disabled users where you can

An honest accessibility statement completes the loop by telling users what is known not to work yet and how to report a problem. Our free accessibility statement generator produces a draft to edit.

Ecommerce ADA compliance checklist extras: product pages, carts and checkout

Online stores have patterns that fail more often than content pages:

• Product images have alt text that describes the product, not the file name (row 1)
• Size, color and variant selectors work with a keyboard and announce the selected option (rows 20, 35)
• Quantity steppers and "add to cart" buttons have accessible names, not just icons (rows 27, 35)
• Cart updates and "added to cart" confirmations are announced as status messages (row 36)
• Checkout errors name the field and the fix, and the order can be reviewed before payment (row 34)
• Payment and session timeouts warn the user and can be extended (row 22)
• CAPTCHA has an accessible alternative, not only a visual puzzle (rows 1, 34)
• Embedded third-party payment frames are tested too, because they are part of your checkout journey

Common questions about ADA website compliance

These are general explanations, not legal advice for your situation.

How do I know if my website is ADA compliant?

Combine automated and manual testing, because neither alone is enough: a scan for machine-detectable issues, then keyboard, screen reader and contrast checks by hand, and a specialist audit for a large or complex site. No single tool can answer the question by itself.

What is the difference between ADA and WCAG compliance?

The ADA is the law; WCAG is the technical standard. The Title II rule makes WCAG 2.1 AA the legal requirement for governments. For private businesses no regulation names a standard, but WCAG 2.1 AA is the benchmark used in practice.

Can I use an accessibility overlay instead of fixing my site?

No. Overlays try to patch accessibility at page load, address only a fraction of issues and often interfere with screen readers. In April 2025 the FTC finalised an order requiring accessiBe to pay USD 1 million over claims that its tool could make websites compliant. See the evidence on whether accessibility overlays protect you from lawsuits and our full case against overlays.

Who is responsible for ADA compliance on my website?

The organisation that owns the site and serves the public. Developers, agencies, designers and content authors all play a part in keeping it accessible, but responsibility does not transfer to a vendor or a tool.

Are small businesses exempt from ADA website lawsuits?

Title III has no size exemption for public accommodations: a small shop is covered just as a large chain is. Courts have differed on when a website on its own counts as a public accommodation, particularly for businesses with no physical location, so the exposure depends on your circumstances. [VERIFY: describe the split only with cited decisions, or keep this general.]

Which WCAG version should we target?

WCAG 2.1 AA is the legal benchmark: it is the version the Title II rule names. WCAG 2.2 AA is the forward-looking choice. It keeps every 2.1 criterion except 4.1.1 Parsing and adds six more, so building to 2.2 AA covers 2.1 AA as well.

Do we need an accessibility statement?

The ADA does not require one. It is still good practice, because it gives users a way to report problems. The European Accessibility Act is different, because it requires in-scope services to publish information on how they meet its requirements. We cover both in are accessibility statements legally required.

The bottom line

An ADA website compliance checklist comes down to WCAG 2.1 Level AA, and the 36 checks above cover every one of its 50 Level A and AA criteria. Governments are bound by it under the Title II rule. Private businesses are measured against it in practice under Title III. Start with the six-step developer pass: a keyboard walk-through and an automated scan surface the high-impact issues fast. Then add a person for the checks no tool can judge, fix problems at the template and component level, and keep testing as you ship.

Sources

• W3C, Web Content Accessibility Guidelines 2.1
• W3C, How to Meet WCAG 2.1 (Quick Reference)
• W3C, What's new in WCAG 2.2
• ADA.gov, Guidance on Web Accessibility and the ADA (March 2022)
• ADA.gov, fact sheet on the Title II web and mobile app rule
• eCFR, 28 CFR part 35, subpart H
• US Access Board, ICT (Section 508) standards
• WebAIM, The WebAIM Million 2026
• Deque, The Automated Accessibility Coverage Report
• Federal Trade Commission, FTC Approves Final Order Requiring accessiBe to Pay $1 Million (22 April 2025)
• Section508.gov, Fonts and Typography
• Sitejar, benchmark of 304 web agency front pages (2026)

This guide is general information, not legal advice.