ADA Website Compliance Checklist 2026: Complete WCAG 2.1 AA Guide
ADA website lawsuits surpassed 4,000 filings in 2024, a 37% year-over-year increase. In 2025, the DOJ formally adopted WCAG 2.1 Level AA as the standard for state and local government websites. Private-sector lawsuits follow the same benchmark. This checklist covers every requirement you need to meet.
The Americans with Disabilities Act requires websites that qualify as “places of public accommodation” to be accessible to people with disabilities. While the ADA text does not name a specific technical standard, courts, settlement agreements, and the Department of Justice consistently reference WCAG 2.1 Level AA as the compliance benchmark. This checklist walks through every AA success criterion, organized by the four WCAG principles: Perceivable, Operable, Understandable, and Robust.
Use this page as your reference while auditing. For an automated first pass, run your site through our free AccessScore scanner — it checks the 16 most impactful criteria in seconds and gives you a legal risk tier so you know where you stand before diving into manual testing.
Why This Matters: ADA Lawsuit Snapshot
1. Perceivable
Information and user interface components must be presentable to users in ways they can perceive. This is the most frequently violated principle and accounts for the majority of issues cited in ADA lawsuits.
1.1 Text Alternatives (SC 1.1.1)
Every <img> element has a non-empty alt attribute
Decorative images should use alt="" (empty) — but images conveying information need descriptive text.
Alt text is descriptive and contextually meaningful
"Photo" or "image_001.jpg" is not sufficient. Describe what the image communicates: "Bar chart showing quarterly revenue growth of 15%."
Complex images have long descriptions
Charts, infographics, and diagrams need either a long alt text or a separate text description linked via aria-describedby.
Image buttons have accessible text
Search icons, hamburger menus, and icon-only buttons need aria-label or visible text.
CSS background images conveying meaning have text alternatives
If a background image carries content (not decoration), provide an off-screen text alternative.
CAPTCHAs have accessible alternatives
Audio CAPTCHA, hCaptcha accessible mode, or logic-based challenges must be available.
1.2 Time-Based Media (SC 1.2.1 – 1.2.5)
Prerecorded audio has a text transcript
Podcasts, audio clips, and voice messages need full text transcripts.
Prerecorded videos have synchronized captions
Auto-generated captions must be reviewed for accuracy. YouTube auto-captions are not sufficient for compliance.
Prerecorded videos have audio descriptions (AA)
When visual content is not conveyed by the audio track, a separate audio description track is needed.
Live video has real-time captions
Webinars, live streams, and virtual events need live captioning (CART or AI-assisted with review).
1.3 Adaptable Content (SC 1.3.1 – 1.3.5)
Headings use proper HTML heading tags (h1-h6) in order
Don't skip levels (h1 then h3). Screen readers use heading hierarchy to navigate. Styled bold text is not a heading.
Lists use <ul>, <ol>, or <dl> markup
Screen readers announce list context ("list of 5 items"), helping users understand content structure.
Data tables have <th> elements with scope attributes
Tables must use proper header cells so screen readers can associate data cells with their headers.
Form inputs are programmatically associated with labels
Use <label for="id"> or aria-label. Placeholder text alone is not a label.
Content order is meaningful in the DOM
If CSS is disabled, content should still read in a logical sequence. Don't rely on visual positioning alone.
Input fields identify their purpose (SC 1.3.5 AA)
Use autocomplete attributes on common fields (name, email, address, phone) so browsers and assistive tech can autofill.
1.4 Distinguishable (SC 1.4.1 – 1.4.13)
Color is not the only means of conveying information (SC 1.4.1)
Error states, required fields, and chart data must use more than color — add text, icons, or patterns.
Text has minimum 4.5:1 contrast ratio (SC 1.4.3 AA)
Large text (18pt or 14pt bold) needs 3:1. Use a contrast checker tool. Gray-on-white is the most common failure.
Text can be resized to 200% without loss (SC 1.4.4 AA)
Zoom your browser to 200%. Content should reflow without horizontal scrolling or text being clipped.
Images of text are not used when real text could work (SC 1.4.5 AA)
Logos are exempted. But headings, buttons, and nav items must be real HTML text, not images of text.
Content reflows at 320px width without horizontal scroll (SC 1.4.10 AA)
At 1280px viewport width with 400% zoom, no horizontal scroll should be needed except for data tables, maps, or diagrams.
Non-text contrast is 3:1 for UI components (SC 1.4.11 AA)
Borders, icons, focus indicators, and form field outlines must be visible against their backgrounds.
Text spacing can be overridden without content loss (SC 1.4.12 AA)
Users must be able to increase line height to 1.5x, letter spacing to 0.12em, and word spacing to 0.16em.
Hover/focus content can be dismissed and is persistent (SC 1.4.13 AA)
Tooltips and popovers that appear on hover must be dismissible (Esc), hoverable (pointer can enter the tooltip), and persistent (don't disappear until the user dismisses them).
2. Operable
User interface components and navigation must be operable by all users, including those who cannot use a mouse. Keyboard accessibility failures are among the most commonly cited violations in ADA lawsuits.
2.1 Keyboard Accessible (SC 2.1.1 – 2.1.4)
All functionality is operable via keyboard alone (SC 2.1.1)
Tab through your entire site. Every link, button, form field, dropdown, and interactive element must be reachable and activatable.
No keyboard traps exist (SC 2.1.2)
Users must be able to tab away from any focused element. Common traps: modals without escape handling, embedded video players, rich text editors.
Custom keyboard shortcuts can be turned off (SC 2.1.4 AA)
If your site uses single-character keyboard shortcuts, users must be able to disable or remap them.
2.2 Enough Time (SC 2.2.1 – 2.2.2)
Time limits can be extended or turned off (SC 2.2.1)
Session timeouts, checkout timers, and form auto-saves must allow users to request more time (at least 10x the default).
Auto-updating content can be paused or stopped (SC 2.2.2)
News tickers, auto-refreshing feeds, and carousels must have pause/stop controls.
2.3 Seizures and Physical Reactions (SC 2.3.1)
No content flashes more than 3 times per second
Flashing content can trigger seizures. This includes animated GIFs, video content, and CSS animations. When in doubt, keep animations under 3 flashes per second.
2.4 Navigable (SC 2.4.1 – 2.4.10)
Skip navigation link is present (SC 2.4.1)
A "Skip to main content" link should be the first focusable element on every page.
Pages have descriptive, unique titles (SC 2.4.2)
Each page should have a <title> that describes its specific content. "Home" or "Page 1" is not descriptive.
Focus order matches visual reading order (SC 2.4.3)
Tab order should follow left-to-right, top-to-bottom visual flow. Avoid positive tabindex values.
Link text describes the destination (SC 2.4.4)
"Click here" and "Read more" are not descriptive. Use "Read our pricing details" or add aria-label for context.
Multiple navigation mechanisms exist (SC 2.4.5 AA)
Provide at least two ways to reach any page: navigation menu + site search, or navigation + sitemap.
Headings and labels describe their content (SC 2.4.6 AA)
Headings should accurately describe the section they introduce. Labels should describe what the input expects.
Focus indicator is visible (SC 2.4.7 AA)
When tabbing through the page, the currently focused element must have a visible outline or highlight. Never use outline: none without a replacement.
2.5 Input Modalities (SC 2.5.1 – 2.5.4)
Pointer gestures have single-pointer alternatives (SC 2.5.1 AA)
If your site uses pinch-zoom, multi-finger swipes, or path-based gestures, provide single-click alternatives.
Pointer actions can be cancelled (SC 2.5.2 AA)
Actions should fire on up-event (mouseup/touchend), not down-event, so users can move away to cancel.
Visible labels match accessible names (SC 2.5.3 AA)
If a button displays "Search", its accessible name must contain "Search" (not just aria-label="Find items").
Motion-activated functions have UI alternatives (SC 2.5.4 AA)
Shake-to-undo or tilt-to-scroll must have button equivalents. Users must be able to disable motion activation.
3. Understandable
Information and the operation of the user interface must be understandable. This covers language, predictability, and input assistance.
3.1 Readable (SC 3.1.1 – 3.1.2)
Page language is declared in HTML (SC 3.1.1)
<html lang="en"> (or appropriate language code). Screen readers use this to select the correct pronunciation engine.
Language changes within content are marked (SC 3.1.2 AA)
If a page in English contains a paragraph in Spanish, wrap it in <span lang="es">. This ensures correct pronunciation.
3.2 Predictable (SC 3.2.1 – 3.2.4)
Focusing an element does not trigger a context change (SC 3.2.1)
Tabbing to a dropdown should not automatically submit a form or navigate away.
Changing an input does not auto-submit without warning (SC 3.2.2)
Selecting a radio button or dropdown value should not automatically navigate away. Provide an explicit submit action.
Navigation is consistent across pages (SC 3.2.3 AA)
Navigation menus should appear in the same location and order across all pages.
Components with the same function are identified consistently (SC 3.2.4 AA)
A search function should be labeled "Search" everywhere, not "Search" on one page and "Find" on another.
3.3 Input Assistance (SC 3.3.1 – 3.3.4)
Error messages identify the field and describe the error (SC 3.3.1)
"Error in form" is not helpful. Use "Email address is required" or "Password must be at least 8 characters."
Required fields are identified before submission (SC 3.3.2)
Mark required fields visually and programmatically (aria-required="true" or required attribute).
Error suggestions are provided when possible (SC 3.3.3 AA)
If validation fails, suggest the correct format: "Enter date as MM/DD/YYYY" instead of just "Invalid date."
Legal/financial submissions are reversible or confirmable (SC 3.3.4 AA)
For purchases, legal agreements, or data deletion: provide a review step, confirmation dialog, or the ability to undo within a reasonable time.
4. Robust
Content must be robust enough to be reliably interpreted by a wide variety of user agents, including assistive technologies.
4.1 Compatible (SC 4.1.1 – 4.1.3)
HTML is well-formed with no duplicate IDs (SC 4.1.1)
Duplicate IDs break label associations and ARIA references. Run your HTML through the W3C validator.
All UI components have accessible names and roles (SC 4.1.2)
Custom widgets (tabs, accordions, modals, date pickers) need proper ARIA roles, states, and properties.
Status messages use ARIA live regions (SC 4.1.3 AA)
"Item added to cart", "Form submitted successfully", or error counts must be announced to screen readers via aria-live="polite" or role="status".
Priority Order: What to Fix First
Not all violations carry equal legal risk. Based on analysis of ADA lawsuit complaints and settlement agreements, here are the issues most frequently cited by plaintiffs, ranked by how often they appear in legal filings:
Missing image alt text
Referenced in 86% of ADA web complaints
Unlabeled form inputs
Referenced in 68% of complaints
Empty links and buttons
Referenced in 54% of complaints
Missing document language
Referenced in 42% of complaints
Insufficient color contrast
Referenced in 38% of complaints
Missing skip navigation
Referenced in 31% of complaints
Missing page titles
Referenced in 28% of complaints
Keyboard inaccessible elements
Referenced in 24% of complaints
How to Use This Checklist
A complete ADA compliance audit combines automated scanning with manual testing. We recommend the following workflow:
Step 1: Run an automated scan
Use AccessScore, axe DevTools, or WAVE to catch low-hanging fruit. Automated tools find roughly 30-40% of WCAG violations but cover the most commonly cited issues.
Step 2: Keyboard-test every page template
Unplug your mouse and tab through each unique page type. Can you reach and operate every interactive element? Can you tell where focus is at all times?
Step 3: Screen reader test key flows
Test with NVDA (free, Windows), VoiceOver (free, macOS/iOS), or JAWS. Navigate your main pages, complete a form, and go through checkout.
Step 4: Check color contrast
Use a contrast checking tool on all text/background combinations. Pay special attention to placeholders, disabled states, and link text.
Step 5: Test at 200% zoom and on mobile
Zoom your browser to 200%. Is all content still usable without horizontal scrolling? Does your mobile experience maintain accessibility?
Step 6: Document and prioritize
Create a spreadsheet of all findings, ranked by legal risk. Fix CRITICAL and HIGH issues first. Keep the document as evidence of your good-faith compliance efforts.
Legal Context: ADA and WCAG in 2026
In April 2024, the DOJ published a final rule under Title II of the ADA requiring state and local governments to make their websites conform to WCAG 2.1 Level AA. While this rule applies directly to government entities, it has significant implications for the private sector: courts interpreting Title III (private businesses) now have explicit DOJ guidance that WCAG 2.1 AA is the standard.
The European Accessibility Act (EAA) took effect in June 2025, requiring digital products and services sold in the EU to meet accessibility standards closely aligned with WCAG 2.1 AA. If your website serves EU customers, compliance is now a legal obligation under EU law as well.
In practical terms, WCAG 2.1 AA is now the de facto global standard for website accessibility compliance. Meeting this standard puts you in the strongest defensible position regardless of which jurisdiction your users are in.
Start Your ADA Compliance Check
Run your website through AccessScore to get your compliance score, legal risk tier, and the top issues to fix — in seconds, for free.
Scan Your Website Now — Free16 automated checks. Legal risk assessment. No signup required.