ADA Website Compliance Checklist for 2025: Every Item You Need to Check
# ADA Website Compliance Checklist for 2025: Every Item You Need to Check
Checklists work. That's why pilots use them before every flight, surgeons use them before every procedure, and smart business owners use them before their websites become litigation targets.
In 2025, over 5,100 federal ADA website accessibility lawsuits were filed — a 37% increase from the year before. Most of those defendants had no idea their website had issues until they received a demand letter.
This checklist helps you spot problems before a plaintiff's attorney does. We've organized it by category and priority level so you know what to fix first.
A quick honest note before you start: this checklist covers the most common and testable WCAG 2.1 AA requirements. No checklist — and no automated tool — can guarantee full legal compliance. A clean scan plus this checklist gets you most of the way there, but complex interactions and edge cases still benefit from human review.
With that said, let's get to work.
How to Use This Checklist
Each item is labeled with:
- Priority: 🔴 Critical | 🟡 Important | 🟢 Nice-to-Have
- WCAG Criterion: The specific standard it maps to
- Type: Technical (code) | Design (visual) | Content (copy) | Legal (documentation)
Start with 🔴 Critical items. These are the most commonly cited violations in lawsuits and the most likely to affect users with disabilities right now.
Section 1: Images and Visual Content
🔴 1.1 — All meaningful images have alt text
- WCAG: 1.1.1 Non-text Content
- Type: Technical / Content
- Every
tag should have analtattribute describing what the image shows - Decorative images should have
alt=""(empty) so screen readers skip them - Bad:
| Good:

🔴 1.2 — Complex images have extended descriptions
- WCAG: 1.1.1 Non-text Content
- Type: Content
- Charts, graphs, infographics, and diagrams need text descriptions that convey the same information
- A caption saying "Figure 1: Sales growth" is not enough — describe the actual data
🟡 1.3 — Images of text are avoided
- WCAG: 1.4.5 Images of Text
- Type: Design / Technical
- Don't use images to display text that could be real HTML text
- Exception: logos and text that is essential to the message
🟡 1.4 — Video has captions
- WCAG: 1.2.2 Captions (Prerecorded)
- Type: Content
- All pre-recorded video with spoken audio needs synchronized captions
- Auto-generated captions (YouTube, etc.) must be reviewed for accuracy
🟢 1.5 — Audio-only content has transcripts
- WCAG: 1.2.1 Audio-only
- Type: Content
- Podcasts and audio clips need text transcripts
Section 2: Color and Visual Design
🔴 2.1 — Normal text meets 4.5:1 contrast ratio
- WCAG: 1.4.3 Contrast (Minimum)
- Type: Design
- Small text (below 18pt or 14pt bold) needs at least 4.5:1 contrast against background
- Test tool: WebAIM Contrast Checker (free)
🔴 2.2 — Large text meets 3:1 contrast ratio
- WCAG: 1.4.3 Contrast (Minimum)
- Type: Design
- Text 18pt+ or 14pt+ bold can use the lower 3:1 threshold
🔴 2.3 — Information is not conveyed by color alone
- WCAG: 1.4.1 Use of Color
- Type: Design
- Required form fields shouldn't only be marked with a red border — also add an asterisk or label
- Error messages shouldn't only turn text red — add an icon or explicit "Error:" label
🟡 2.4 — Focus indicators are visible
- WCAG: 2.4.7 Focus Visible
- Type: Design / Technical
- When a user navigates with Tab, the focused element must be visually highlighted
- Many sites override
outline: nonein CSS — this breaks keyboard navigation entirely
🟡 2.5 — UI components meet 3:1 contrast against background
- WCAG: 1.4.11 Non-text Contrast (WCAG 2.1)
- Type: Design
- Buttons, form fields, checkboxes, and other UI components need 3:1 contrast ratio
Section 3: Keyboard and Navigation
🔴 3.1 — All functionality works with keyboard only
- WCAG: 2.1.1 Keyboard
- Type: Technical
- Every link, button, form field, and interactive element must be reachable with Tab and operable with Enter/Space
- Test: unplug your mouse and navigate your entire site
🔴 3.2 — No keyboard traps
- WCAG: 2.1.2 No Keyboard Trap
- Type: Technical
- Users must be able to navigate OUT of every component (especially modals and custom widgets) using only the keyboard
- Modals should close with Escape
🔴 3.3 — Skip navigation link is present
- WCAG: 2.4.1 Bypass Blocks
- Type: Technical
- A "Skip to main content" link should be the first focusable element on every page
- It can be visually hidden but must appear on focus
🟡 3.4 — Page has a logical tab order
- WCAG: 1.3.2 Meaningful Sequence / 2.4.3 Focus Order
- Type: Technical
- Tab order should follow the visual/reading order of the page
- Avoid using
tabindexvalues greater than 0 to reorder focus
🟡 3.5 — Dropdown menus are keyboard accessible
- WCAG: 2.1.1 Keyboard
- Type: Technical
- Navigation menus that open on hover should also open on focus/Enter and close on Escape
Section 4: Forms
🔴 4.1 — All form inputs have visible labels
- WCAG: 1.3.1 Info and Relationships / 3.3.2 Labels or Instructions
- Type: Technical / Design
- Every
,, andneeds an associatedelement - Placeholder text alone is NOT a sufficient label
🔴 4.2 — Required fields are identified
- WCAG: 3.3.2 Labels or Instructions
- Type: Technical / Content
- Required fields must be marked with more than just color
- Include
requiredattribute on inputs for screen reader support
🔴 4.3 — Error messages are descriptive and linked to the field
- WCAG: 3.3.1 Error Identification / 3.3.3 Error Suggestion
- Type: Technical / Content
- "Invalid input" is not enough — say "Please enter a valid email address"
- Error message should be associated with the specific field that has the error
🟡 4.4 — Form has autocomplete attributes where appropriate
- WCAG: 1.3.5 Identify Input Purpose (WCAG 2.1)
- Type: Technical
- Add
autocomplete="name",autocomplete="email", etc. to relevant fields - Helps users with cognitive disabilities and reduces input errors
🟡 4.5 — CAPTCHA has an accessible alternative
- WCAG: 1.1.1 Non-text Content
- Type: Technical
- If you use CAPTCHA, provide an audio or other non-visual alternative
- Better option: use honeypot techniques that don't require user interaction
Section 5: Structure and Semantics
🔴 5.1 — Page has a meaningful title
- WCAG: 2.4.2 Page Titled
- Type: Technical / Content
- Every page's
tag should describe the page content - Don't use "Home" — use "Accessibility Audit Tool | CheckMyADA"
🔴 5.2 — Heading hierarchy is logical
- WCAG: 1.3.1 Info and Relationships
- Type: Technical / Content
- Only one
per page;throughin descending order - Don't skip from
to— screen readers use headings to navigate
🔴 5.3 — Language is declared in HTML
- WCAG: 3.1.1 Language of Page
- Type: Technical
must be set (or appropriate language code)- If content switches languages mid-page, use
langattribute on that element
🟡 5.4 — Landmark regions are used
- WCAG: 1.3.1 Info and Relationships
- Type: Technical
- Use semantic HTML:
,,,, - Or add ARIA roles:
role="navigation",role="main", etc.
🟡 5.5 — Lists use proper list markup
- WCAG: 1.3.1 Info and Relationships
- Type: Technical
- Navigation menus, bullet lists, and numbered steps should use
,, andelements
Section 6: Links and Buttons
🔴 6.1 — Link text is descriptive
- WCAG: 2.4.4 Link Purpose
- Type: Content
- Avoid "click here," "read more," "learn more" without context
- Good: "Download our ADA compliance checklist PDF"
- Bad: "Click here"
🔴 6.2 — Buttons have descriptive labels
- WCAG: 4.1.2 Name, Role, Value
- Type: Technical / Content
- Icon-only buttons need
aria-label:
🟡 6.3 — Links that open in new tabs warn users
- WCAG: 3.2.2 On Input (related)
- Type: Content / Technical
- Links opening in a new tab should indicate this: "Opens in new window" or an icon with
aria-label
🟡 6.4 — Links are distinguishable from body text
- WCAG: 1.4.1 Use of Color
- Type: Design
- Links should not rely solely on color to be distinguishable — add underline or another visual indicator
Section 7: PDFs and Documents
🟡 7.1 — PDFs are tagged for accessibility
- WCAG: 1.1.1 / 1.3.1
- Type: Technical
- Scanned/image PDFs are not accessible — text must be real text, not an image
- PDFs should have proper heading structure, alt text, and reading order
🟡 7.2 — Downloadable files have accessible alternatives
- WCAG: 1.1.1
- Type: Content
- Consider providing critical information in HTML format instead of (or in addition to) PDF
🟢 7.3 — Office documents use accessibility features
- WCAG: 1.1.1
- Type: Technical
- Word and PowerPoint files offered for download should use built-in accessibility tools
Section 8: Legal and Documentation
🟡 8.1 — Accessibility statement is published
- Not a WCAG criterion, but best practice and required by some laws
- Type: Legal
- Include: commitment to accessibility, standard you follow, known limitations, contact information, feedback mechanism
🟡 8.2 — Contact method for accessibility issues is provided
- Type: Legal
- Users should have a way to request accessible content or report barriers
- Phone, email, or contact form are all acceptable
🟢 8.3 — Regular accessibility audit schedule is documented
- Type: Legal
- Document when your last audit was and when the next one is scheduled
- Annual audits are a reasonable baseline; more frequent if site changes often
🟢 8.4 — Third-party widget accessibility is evaluated
- Type: Technical / Legal
- Embedded chat widgets, booking systems, and social feeds affect your site's overall accessibility
- Check vendor accessibility documentation; note any known limitations in your accessibility statement
Priority Summary: What to Fix First
If you're overwhelmed, work through this order:
Immediate (this week):
1. Add alt text to all images missing it
2. Fix color contrast failures on body text
3. Add visible labels to all form inputs
4. Add descriptive link text (replace "click here")
5. Add a skip navigation link
Short-term (this month):
6. Ensure all functionality works with keyboard only
7. Fix heading hierarchy issues
8. Add error descriptions to form validation
9. Declare page language in HTML
10. Post an accessibility statement
Ongoing:
- Caption new videos
- Review PDFs for accessibility
- Test major updates with keyboard navigation
- Run quarterly automated scans
How to Audit Your Site Against This Checklist
Step 1: Automated scan first. Use the free scan at CheckMyADA to identify the most common technical violations automatically. This covers roughly 30-40% of WCAG criteria.
Step 2: Keyboard test. Unplug your mouse (or put it aside) and navigate your entire site using only Tab, Enter, Space, and arrow keys. Try filling out your contact form. Try navigating your menu. Note anything that doesn't work.
Step 3: Color contrast check. Use browser extensions like Axe or Colour Contrast Analyser to check your text against the 4.5:1 threshold.
Step 4: Screen reader test. Download NVDA (free, Windows) or use VoiceOver (built-in on Mac) and listen to your homepage. Notice anything confusing or missing?
Step 5: Review the legal section. Does your site have an accessibility statement? A contact method for accessibility issues?
For a detailed guide on running this audit, see our article: How to Do a Website Accessibility Audit in 5 Minutes.
FAQ
Q: Does completing this checklist mean my site is fully ADA compliant?
A: Not necessarily. This checklist covers the most common WCAG 2.1 AA criteria, but compliance is ultimately determined by courts — and courts have sometimes applied stricter standards. A clean checklist significantly reduces your risk but isn't a legal guarantee. Document your efforts; they demonstrate good faith.
Q: How often should I run through this checklist?
A: At a minimum, after any significant website redesign or content update, and on a scheduled basis at least once per year. Sites that change frequently (e-commerce, news) should audit more often.
Q: My website is on Squarespace/Wix/Shopify — does the platform handle compliance for me?
A: Platforms handle some things (like semantic HTML structure) but not everything. You're still responsible for the content you add: alt text on images you upload, descriptive link text you write, captions on videos you embed. Don't assume the platform covers everything.
Q: Which WCAG version should I be targeting?
A: WCAG 2.1 Level AA is the current practical standard for legal compliance in the U.S. WCAG 2.2 was released in 2023 and adds several new criteria — it's worth reviewing, though courts haven't yet widely adopted it.
Q: I have a one-page website with just my phone number and hours. Do I need to worry about this?
A: Yes, though your risk is lower. The basics still apply: readable text contrast, accessible contact form if you have one, and a lang attribute on your HTML. Simple sites can be made accessible in under an hour.
Start Your Compliance Check Today
Use CheckMyADA's free scan to automatically check your site against the technical items on this list. The scan takes under two minutes and shows you exactly which issues need attention — with references to the WCAG criteria they violate.
Then use this checklist to handle the items that need human review.
