ADA Compliance for Websites: Requirements, Checklist & Testing Guide
ADA Compliance for Websites: Requirements, Checklist & Testing Guide
You’ve heard the case for ADA website compliance — the legal risk, the business case, the moral obligation. Now you need the specifics: what exactly to check, how to test it, and what methodology actually catches the barriers that matter. This article is the tactical companion — a structured checklist of ADA website requirements organized by category, plus the three-layer testing approach that separates a real accessibility evaluation from a surface-level scan.
The standard applied in virtually all ADA enforcement and settlements is WCAG 2.1 Level AA (with 2.2 increasingly expected). The checklist below maps to those criteria. For the full legal framework and compliance path, BarrierBreak’s ADA compliance guide covers the landscape comprehensively.
(General information, not legal advice.)
ADA Website Compliance Checklist
Images and Non-Text Content
- Every informative image has meaningful alt text describing its purpose — not “image” or a filename.
- Decorative images have empty alt text (
alt="") so screen readers skip them. - Complex images (charts, infographics) have a long description or linked data table.
- Icons used as controls have accessible names — not icon-only buttons.
Video and Multimedia
- All pre-recorded video with audio has synchronized captions (WCAG 1.2.2).
- Live video has real-time captions (WCAG 1.2.4).
- Pre-recorded video with important visual content has audio descriptions (WCAG 1.2.5).
- Media player controls are keyboard-operable with accessible names.
Color and Visual Design
- Text meets minimum contrast ratio: 4.5:1 for normal text, 3:1 for large text (WCAG 1.4.3).
- Non-text UI elements (buttons, form borders, icons) meet 3:1 contrast against adjacent colors (WCAG 1.4.11).
- Color is never the sole means of conveying information — errors, status, links use text or symbols too (WCAG 1.4.1).
- Text is resizable to 200% without loss of content or functionality (WCAG 1.4.4).
Keyboard and Navigation
- All functionality accessible by keyboard — every link, button, form field, and interactive element reachable by Tab and activatable without a mouse (WCAG 2.1.1).
- No keyboard traps — users can always navigate away from any element (WCAG 2.1.2).
- Visible focus indicator on every interactive element (WCAG 2.4.7).
- Logical tab order that follows the visual reading sequence (WCAG 2.4.3).
- Skip navigation link present so keyboard users can bypass repetitive content.
Structure and Semantics
- Heading hierarchy is logical (
h1→h2→h3) with no skipped levels. - Lists use list markup (
<ul>,<ol>,<li>) — not dashes or manually typed numbers. - Data tables have headers marked with
<th scope="col/row">. - Landmark regions (
<nav>,<main>,<header>,<footer>) are present and properly used. - Page has a descriptive
<title>and a defined language attribute (lang="en").
Forms and Input
- Every form field has a visible, programmatically associated label (WCAG 1.3.1).
- Required fields are identified in text — not only by asterisk or color.
- Error messages identify the field, describe the error, and suggest a fix (WCAG 3.3.1, 3.3.3).
- Autocomplete attributes are present on fields collecting personal data — name, email, address, payment (WCAG 1.3.5).
Links and Interactive Elements
- Link text is descriptive — indicates the destination, not “click here” or “read more” without context.
- Links are visually distinguishable from surrounding text (not by color alone).
- Custom interactive elements (accordions, tabs, modals) use correct ARIA roles and keyboard patterns.
Dynamic Content
- Content that updates dynamically (notifications, cart updates, error messages) uses ARIA live regions to announce changes to screen readers (WCAG 4.1.3).
- Session timeouts warn users before expiry and allow extension (WCAG 2.2.1).
- Auto-playing media can be paused or stopped by the user (WCAG 1.4.2).
ADA Website Testing: The Three-Layer Methodology
A checklist tells you what to look for. A testing methodology tells you how to find it. ADA compliance testing requires three layers — not because any single layer is wrong, but because each catches different things.
Layer 1: Automated scanning
Run an automated accessibility checker (axe DevTools, WAVE, Lighthouse) across your site. This catches objective, code-level issues quickly: missing alt text, contrast failures, empty links, missing form labels, absent page language.
Get BarrierBreak’s stories in your inbox
Join Medium for free to get updates from this writer.
What it catches: the machine-verifiable subset — roughly a third of real barriers. What it misses: everything requiring human judgment.
Layer 2: Manual expert testing
Accessibility specialists evaluate the site against WCAG criteria that require interpretation: whether alt text is meaningful, whether heading hierarchy is logical, whether error messages help, whether reading order makes sense. This is also where custom components (modals, carousels, accordions) get tested for correct ARIA and keyboard behavior.
What it catches: the judgment-based issues automated tools structurally cannot evaluate.
Layer 3: Assistive technology testing
Test core user journeys — sign-up, purchase, account management, content browsing — using screen readers (NVDA, JAWS, VoiceOver), keyboard-only navigation, and other assistive technologies. This layer answers the ultimate question: can a user with a disability actually complete the task?
What it catches: real-world usability barriers that neither code analysis nor checklist review surface.
All three layers together constitute a credible ADA accessibility audit. Organizations that want professional-grade testing often work with specialists — the team at BarrierBreak runs all three layers with testers who include daily assistive technology users.
Common ADA Compliance Testing Mistakes
- Automated scan = “we’ve been audited.” It’s one-third of an audit at best.
- Testing the homepage only. Check every page type, especially forms, checkout, and authenticated content.
- No assistive technology testing. A site can pass manual review and still fail a screen reader user.
- Testing once. Products change; accessibility regresses without periodic re-evaluation.
- Trusting overlays. They don’t fix the underlying code and rarely achieve WCAG conformance.
Conclusion
ADA website compliance comes down to meeting WCAG 2.1/2.2 Level AA across every page type and every user interaction on your site. This checklist covers the specific requirements — images, video, color, keyboard access, structure, forms, links, and dynamic content — and the three-layer testing methodology (automated, manual, assistive technology) ensures you’re catching the full range of barriers, not just the machine-detectable fraction. Use the checklist to know what to look for, the testing layers to find what’s actually there, and treat both as an ongoing practice rather than a one-time project.
8. FAQ
What are the specific ADA website requirements? The ADA itself doesn’t list technical requirements for websites. Courts and regulators apply WCAG 2.1 Level AA as the standard, which includes approximately 50 success criteria covering images, video, color contrast, keyboard access, forms, structure, and dynamic content.
What’s the difference between an ADA website audit and an automated scan? An automated scan catches only machine-verifiable issues — roughly a third of real barriers. A full ADA audit adds manual expert testing and assistive technology testing to evaluate the issues automated tools structurally cannot catch.
Is there an official ADA compliance checklist? There’s no government-issued ADA website checklist. The practical equivalent is a WCAG 2.1/2.2 Level AA checklist — the standard applied in ADA enforcement. The W3C publishes a Quick Reference for WCAG that serves as the authoritative criterion-by-criterion reference.
How do I test my website for ADA compliance? Three layers: (1) automated scanning for code-level issues, (2) manual expert review for judgment-based criteria, and (3) assistive technology testing on core user journeys using screen readers and keyboard navigation.
What does ADA Title II require for websites? The 2024 DOJ Title II rule requires state and local government websites and mobile apps to conform to WCAG 2.1 Level AA. Larger entities (population ≥50,000) had a deadline of April 2026; smaller entities have until April 2027.
How often should ADA compliance be tested? After every significant update and at least annually for a formal audit. Continuous automated monitoring between audits catches regressions early.
