The ADA Website Compliance Checklist

Overview

This ADA website compliance checklist gives a practical, testable list you can use right away. Use it to check pages, forms and templates against common accessibility issues and against the guidance courts and standards reference, such as WCAG 2.1 Level AA. Follow the manual tests, then run automated scans and prioritise fixes by user impact.

Legal and standards context (short)

The ADA is US civil-rights law. The law itself does not contain technical web rules. In practice, courts, settlements and many guidance documents refer to Web Content Accessibility Guidelines, typically WCAG 2.0 or 2.1 at Level AA. For US federal sites, Section 508 is also relevant. Use WCAG 2.1 AA as the working technical target unless you have a different legal requirement.

How to use this checklist

Start with a representative set of pages: the homepage, search/results, three product or service pages, two forms, account pages, and any media pages. For templates and the CMS, test both the rendered HTML and the content authors’ workflows. Do automated scans first, then follow the manual tests listed below.

Quick pass/fail checklist (fast scan)

• Images: every meaningful image has non-empty alt text; decorative images use empty alt or CSS background.
• Headings: pages use one logical heading sequence and headings describe sections.
• Links: link text is descriptive and not just “click here”.
• Keyboard: all interactive controls are reachable and usable by keyboard alone.
• Forms: form fields have labels and error messages are clear.
• Contrast: text meets contrast ratios (4.5:1 normal text; 3:1 large text or UI components).
• Video/audio: captions and transcripts exist for prerecorded media; controls are keyboard accessible.

Detailed checklist by WCAG principle

Perceivable (text alternatives, time-based media, contrast)

• Images and icons: provide alt text for informative images. Test: turn off images in the browser or inspect HTML. Fix: add alt attribute, use role=“img” with accessible name if needed.
• Decorative images: confirm alt=“” or CSS background so screen readers skip them.
• Captions and transcripts: check prerecorded video has captions and an accurate transcript. Live-only streams require captioning strategy.
• Colour contrast: verify normal text meets 4.5:1 and large text meets 3:1. Test with a contrast tool and with greyscale view.

Operable (keyboard, navigation, focus, time)

• Keyboard access: tab through the page. All interactive elements must be reachable and operable. Fix missing tabindex, use native elements when possible.
• Logical focus order: focus should move in reading order. Test by tabbing and watching focus highlight.
• Visible focus: ensure the focus indicator is visible and meets contrast. Do not remove outline unless replaced by an equivalent.
• Skip links and landmarks: add a skip-to-main link and landmark roles (header, main, nav, footer) for faster navigation.
• Timing controls: provide controls or warnings if time limits exist.

Understandable (readable content, predictable behaviour, input assistance)

• Headings and labels: use semantic headings (h2, h3) and ensure form labels are programmatically associated using label elements or aria-labels.
• Error identification: clearly identify errors in forms and provide suggestions to fix them.
• Consistent navigation: keep navigation and controls consistent across pages.

Robust (semantic HTML and ARIA)

• Semantic elements: use native elements (button, a, input) instead of generic clickable divs. Test accessibility tree in browser dev tools.
• ARIA usage: use ARIA to enhance semantics only when native HTML cannot achieve the aim. Avoid redundant or conflicting ARIA attributes.
• Accessible names and roles: ensure each control has a programmatic name and an appropriate role.

Common checks for multimedia and dynamic content

• Video players: keyboard controls, visible play/pause, caption toggle and volume controls. Provide audio-only transcripts where needed.
• Dynamic updates: use ARIA live regions for notifications and test with a screen reader to confirm announcements.
• Animations and motion: provide a way to pause or reduce motion if it causes vestibular issues.

Automated tools and what they catch

Run automated scanners on a sample set of pages. These tools catch missing alt attributes, obvious contrast failures, missing form labels and basic semantic problems. Automated checks do not catch keyboard logic, caption accuracy or meaningful link text. Use automation to find low-hanging fruit, not to approve a site as fully accessible.

Manual test flow (step-by-step)

1. Open the page in a browser. Run an automated scan and save the report.
2. Tab through the page to test keyboard access. Note any skips or traps.
3. Use a screen reader for 3 to 5 minutes on key pages to check reading order and announcements.
4. Turn off images or inspect alt attributes for meaningful images.
5. Check forms: fill with valid and invalid data and note error handling and focus after submit.
6. Test colour contrast and greyscale rendering for visual clues that rely on colour alone.
7. Play video with captions on and verify transcript exists and matches content.

Prioritise fixes: impact versus effort

Not all issues are equal. Use this simple decision framework:

• High impact, low effort: fix first. Examples: missing alt text for key images, broken tab stops, obvious 1:1 contrast failures on CTAs.
• High impact, high effort: schedule into roadmap. Examples: redesign of complex interactive components or a JavaScript-heavy checkout flow.
• Low impact, low effort: bundle into minor releases. Examples: decorative icon aria attributes, non-critical help text.
• Low impact, high effort: re-evaluate. Consider progressive enhancement or alternative solutions.

Common mistakes and how to avoid them

• Relying only on automated scans. Manual testing and assistive technology checks are essential.
• Using ARIA to fix structural problems. Prefer correct semantic HTML first.
• Fixing individual pages without addressing templates and the CMS. Content authors must have accessible controls and guidance.
• Ignoring mobile and responsive states. Test keyboard and touch interactions on mobile viewport sizes.

Acceptance checklist for a release

• Representative pages: automated and manual tests completed and reports attached.
• Key issues: all high-impact defects fixed or scheduled with owner and date.
• Content author guidance: CMS fields enforce required accessibility metadata (alt text, captions) or provide reminders.
• Regression tests: accessibility checks added to CI or pre-release tests.

Summary checklist (printable)

• Alt text on informative images
• Headings reflect structure and sequence
• Descriptive link text
• All controls keyboard operable
• Visible focus state
• Form labels and clear error handling
• Text contrast meets ratios (4.5:1/3:1)
• Captions or transcripts for prerecorded media
• Semantic HTML, careful ARIA use
• Automated scans plus manual testing with screen reader

Where to go next

After you run this checklist, create a remediation plan with owners, estimates and dates. Include training for designers and content authors so fixes stick. If you need legal certainty, consult a lawyer who specialises in accessibility law and standards.