An ADA compliance checklist is a working list of the accessibility requirements your website must meet — mapped to WCAG 2.1 Level AA, the standard U.S. courts and the Department of Justice use to judge ADA Title III cases. Below, the criteria are grouped by the four POUR principles so you can audit your site section by section.
How to use this checklist
This is a lead-magnet you can actually work from. Print it, open your site in one tab and this page in another, and mark each item pass, fail, or needs review. The fastest, most honest starting point is a keyboard test: unplug your mouse and try to use your whole site with the Tab, Enter, Space, and arrow keys. If you get stuck, so do thousands of keyboard and screen reader users.
Two things to know before you start:
- An automated scan catches roughly a third of issues. Tools are great for missing alt text, low color contrast, and empty form labels — but they can’t judge whether your content makes sense when read aloud. The rest needs manual accessibility testing.
- Overlay widgets don’t tick these boxes. A floating accessibility button doesn’t change your underlying code, so it can’t make a failing site pass. Real conformance comes from fixing the HTML, CSS, and components by hand.
The POUR principles in 30 seconds
WCAG organizes everything under four principles, remembered by the acronym POUR. Every checklist item below belongs to one of them.
| Principle | Plain-English meaning | Typical failures |
|---|---|---|
| Perceivable | Users can sense the content (see or hear it) | Missing alt text, low contrast, no captions |
| Operable | Users can navigate and interact | Keyboard traps, no focus indicator, tiny tap targets |
| Understandable | Content and controls behave predictably | Unlabeled forms, vague link text, surprise changes |
| Robust | Code works with assistive technology | Broken ARIA, invalid HTML, custom widgets without roles |
Want the deeper version? See our breakdown of the POUR principles and what Level AA requires.
Perceivable
Make sure information isn’t locked behind a single sense.
- ☐ Every meaningful image has descriptive alt text; decorative images use empty
alt="". See alt text best practices. - ☐ Text and background colors meet a 4.5:1 contrast ratio (3:1 for large text and UI components).
- ☐ Information is never conveyed by color alone (e.g. errors aren’t only marked in red).
- ☐ Pre-recorded video has captions; audio-only content has a transcript.
- ☐ Content reflows to a single column at 320px wide / 400% zoom without horizontal scrolling.
- ☐ Text can be resized to 200% without breaking the layout or hiding content.
- ☐ Images of text are avoided where real text would work (logos excepted).
- ☐ PDFs and documents are tagged and readable — see accessible PDFs.
Operable
Make sure everyone can drive the interface, mouse or not.
- ☐ Every function works with a keyboard — links, buttons, menus, sliders, modals. This is the highest-value test you can run; start with our keyboard navigation guide.
- ☐ There are no keyboard traps — focus can always move away from a component.
- ☐ A visible focus indicator shows where you are as you Tab through the page.
- ☐ A “skip to main content” link lets keyboard users bypass repeated navigation.
- ☐ Tap/click targets are at least 24×24 CSS pixels so motor-impaired users can hit them.
- ☐ Nothing flashes more than three times per second (seizure safety).
- ☐ Moving, auto-playing, or auto-updating content can be paused or stopped.
- ☐ Page titles and heading structure are logical and unique — see headings & landmarks.
- ☐ Focus order follows the visual reading order; managed correctly in menus and dialogs (focus management).
Understandable
Make sure content and controls behave the way people expect.
- ☐ Every form field has a programmatically associated label — placeholder text alone is not a label. See accessible forms.
- ☐ Error messages identify the field and how to fix it, in text, not color or icon alone.
- ☐ Link text is descriptive out of context — “View our return policy,” not “click here.”
- ☐ The page’s language is declared (
<html lang="en">). - ☐ Navigation is consistent across pages; components that look alike behave alike.
- ☐ No surprises — focusing or changing a field doesn’t auto-submit or jump the page.
- ☐ Required fields, formats, and inputs are clearly indicated before submission.
Robust
Make sure your code holds up in real assistive technology.
- ☐ HTML is valid and well-formed — no duplicate IDs, properly nested elements.
- ☐ Custom components (tabs, accordions, modals, carousels) expose the correct name, role, and value via ARIA — see ARIA labels & roles.
- ☐ ARIA is used correctly or not at all — bad ARIA is worse than none; native HTML elements are preferred.
- ☐ Status messages (e.g. “3 results found”) are announced with ARIA live regions.
- ☐ The site is tested in an actual screen reader — NVDA or JAWS on Windows, VoiceOver on Mac/iOS — not just an automated checker.
Don’t stop at the automated scan
Here’s the honest part most checklists skip: tools like axe and WAVE flag the easy wins, but the criteria that get sites sued — keyboard operability, focus order, meaningful labels, working ARIA — are exactly the ones automation can’t judge. That’s why a credible process pairs a scan with hands-on review. Read automated vs manual testing for the full breakdown, and see the U.S. government’s plain-language overview at Section508.gov and WebAIM for technique-level guidance.
Quick reference: which tool catches what
| Method | Catches | Misses |
|---|---|---|
| Automated scan | Alt text, contrast, empty labels, some ARIA | Keyboard, focus, logical order, link clarity |
| Keyboard test | Traps, missing focus, unreachable controls | Whether labels read sensibly aloud |
| Screen reader test | Real announced experience, ARIA correctness | Visual contrast, layout reflow |
| Expert manual audit | Everything above, plus edge cases | (this is the comprehensive method) |
Why this matters — and what to do next
Thousands of ADA website lawsuits are filed in the U.S. every year, and a demand letter can arrive whether or not you’ve ever heard of WCAG. Working through this checklist genuinely reduces both your risk and the barriers real users face. But checklists have a ceiling: they tell you what to look for, not whether you’ve judged each item correctly.
This page is a technical guide, not legal advice — if you’ve received a legal threat, talk to an attorney. For the technical side, Curbcut handles it the right way: real people, manually remediating your actual code to WCAG 2.1 AA, with the documentation (and a VPAT if you need one) to prove it. No overlay, no shortcuts.
Ready to see where you stand? Run a free accessibility scan for a baseline, or book a full audit to have an expert work this entire checklist for you.