Service 5 min read
ADA Compliance & Accessibility Audits — Our Service
From €490: a full WCAG 2.1 AA audit with remediation roadmap and Accessibility Statement. Audit fee credited against any build or remediation project.
Quick Answer — What is ADA Website Compliance?
ADA website compliance in 2026 means your website meets WCAG 2.1 Level AA — the Web Content Accessibility Guidelines standard applied by US courts under Title III of the Americans with Disabilities Act. A compliant website must be Perceivable (content accessible including via screen readers), Operable (all functionality usable by keyboard alone), Understandable (content and interface predictable and error-tolerant), and Robust (compatible with assistive technology). The DOJ issued a final rule in April 2024 confirming WCAG 2.1 AA as the applicable standard. Non-compliance exposes US businesses to demand letters and federal lawsuits, with average resolution costs of $25,000–$150,000.
ADA website lawsuits have increased every year since 2017. A business whose website has never received a single accessibility complaint can receive a demand letter on a Tuesday morning from a firm that scanned 50,000 sites over the weekend. This checklist covers every WCAG 2.1 AA requirement you need to know — rated by litigation frequency, with specific fixes for the most dangerous failures.
The Legal Context — Title III, the DOJ Rule, and Where Things Stand
Title III of the ADA prohibits discrimination by "places of public accommodation" — businesses that provide goods or services to the public. US courts have consistently held, since at least 2017 and now with settled case law in most circuits, that commercial websites are places of public accommodation subject to Title III.
The central question — "what standard does my website have to meet?" — was answered definitively in April 2024 when the Department of Justice published its final rule under Title II (government entities) explicitly adopting WCAG 2.1 AA. While the final Title III rule covering private businesses is still pending, every court handling Title III accessibility cases has applied WCAG 2.1 AA as the relevant standard. For practical compliance purposes, WCAG 2.1 AA is the floor.
What changed between 2022 and 2026
The volume of ADA website accessibility lawsuits filed in US federal district courts has increased every year since 2017. The plaintiff bar that specialises in these cases has industrialised the process: automated scanning tools identify WCAG failures across thousands of websites simultaneously, generating a pipeline of potential defendants.
The economic logic for defendants is straightforward: settling costs $10,000–$25,000 plus legal fees, typically in the $8,000–$15,000 range; litigating through motion practice costs $30,000–$80,000 even when you prevail. Most businesses settle.
Who Is at Risk — and How Much Does a Lawsuit Cost?
Lawsuits concentrate in industries where the plaintiff bar has identified systematic, easily documented failures and sufficient defendant financial capacity to make settlement worthwhile. High-risk sectors include:
- E-commerce and retail — product image alt text failures, inaccessible checkout flows
- Healthcare — inaccessible appointment booking, form label failures
- Hospitality — online reservation systems, menu PDFs without text alternatives
- Financial services — inaccessible calculator tools, PDF disclosures without accessible versions
- Law firms — contact form inaccessibility, inaccessible PDF documents
- Education and healthcare — inaccessible registration and learning management interfaces
Proprietary Data
Our own analysis of 500 local service business websites found that 82% failed at least one WCAG 2.1 AA criterion detectable by automated scanning — meaning they would generate a finding in an automated accessibility sweep.
The WCAG 2.1 AA Checklist — 28 Requirements Explained
WCAG 2.1 Level AA has 50 success criteria across four principles. The following 28 are the most commonly tested in ADA litigation and the most practically significant for US business websites. Each is rated by its litigation frequency (how often it appears in ADA complaints).
Principle 1: Perceivable
1.1 — Text Alternatives
SC 1.1.1
★★★★★
HIGH RISK
Every informative image must have descriptive alt text. Decorative images must have empty alt attributes (alt=""). An image of a product with alt="image1.jpg" fails. An image of a product with alt="Red leather sofa, 3-seater, shown from front angle" passes. This is the single most common failure in e-commerce ADA lawsuits.
1.2 — Captions for Video
SC 1.2.2
★★★★☆
HIGH RISK
Pre-recorded video content with audio must have synchronised captions. Auto-generated captions are not compliant unless reviewed and corrected for accuracy. YouTube's auto-captions typically have 6–8% error rates that do not meet the accuracy standard.
1.3 — Meaningful Sequence
SC 1.3.2
★★★☆☆
MODERATE
When the sequence of content matters, the reading order in the DOM must reflect the visual order. CSS that moves elements visually without reordering them in the DOM fails this criterion — screen readers read DOM order, not visual order.
1.4.1 — Use of Colour
SC 1.4.1
★★★★☆
HIGH RISK
Colour must not be the only means of conveying information. A form that shows required fields in red without a text label or asterisk fails. A chart that distinguishes data series by colour alone without labels or patterns fails.
1.4.3 — Contrast Minimum
SC 1.4.3
★★★★★
HIGH RISK
Normal text (under 18pt or 14pt bold) must have a minimum 4.5:1 contrast ratio against its background. Large text must meet 3:1. Light grey text on white — extremely common in modern flat design — almost always fails this criterion. Verify every text/background combination with a colour contrast checker.
1.4.4 — Resize Text
SC 1.4.4
★★★☆☆
MODERATE
Text must be resizable to 200% without loss of content or functionality. Fixed-pixel font sizes that do not scale with browser zoom settings fail. Use relative units (rem, em) for font sizes.
1.4.10 — Reflow
SC 1.4.10
★★★★☆
HIGH RISK
Content must reflow to a single column at 320 CSS pixel viewport width without horizontal scrolling. This is the accessibility expression of mobile-first responsive design — but it is a failure even on a site that looks responsive if horizontal scrolling occurs at narrow viewports.
1.4.11 — Non-Text Contrast
SC 1.4.11
★★★★☆
HIGH RISK
UI component boundaries (input borders, button outlines) and graphical objects that convey information must meet 3:1 contrast against adjacent colours. A text input with a very light grey border against a white background is a common failure.
1.4.12 — Text Spacing
SC 1.4.12
★★★☆☆
MODERATE
Content must remain functional when: line height is set to 1.5× font size; letter spacing to 0.12em; word spacing to 0.16em; paragraph spacing to 2× font size. Test by applying these values as a bookmarklet and checking whether content overlaps or disappears.
Principle 2: Operable
2.1.1 — Keyboard Accessible
SC 2.1.1
★★★★★
HIGH RISK
All functionality must be operable by keyboard alone. Hover-only menus, drag-only interactions, and mouse-triggered events without keyboard equivalents all fail. Test: navigate your entire website using only Tab, Shift+Tab, Enter, Space, and arrow keys — without touching the mouse.
2.1.2 — No Keyboard Trap
SC 2.1.2
★★★★☆
HIGH RISK
Keyboard focus must not become trapped in any component. A modal dialogue that does not return focus to the trigger element when closed, or that cannot be dismissed with Escape, is a keyboard trap.
2.4.1 — Bypass Blocks
SC 2.4.1
★★★★☆
HIGH RISK
A "Skip to main content" link must be present to allow keyboard users to skip repetitive navigation. It should be the first focusable element on the page and visible on focus (it may be visually hidden until focused).
2.4.3 — Focus Order
SC 2.4.3
★★★★☆
HIGH RISK
The keyboard focus order must be logical — following the natural reading order of the page. Focus that jumps unpredictably between unrelated elements, or returns to the top of the page after a modal closes, fails this criterion.
2.4.4 — Link Purpose
SC 2.4.4
★★★★★
HIGH RISK
Link text must describe the destination or purpose. "Click here," "Read more," and "Learn more" without additional context are non-compliant. Links in a list of articles should say "Read: [Article Title]" not "Read more." Add accessible names via aria-label where the visual context cannot be changed.
2.4.7 — Focus Visible
SC 2.4.7
★★★★★
HIGH RISK
All focusable elements must have a clearly visible focus indicator. The single most common developer error causing this failure: outline: none or outline: 0 in the CSS without a visible custom alternative. Remove this pattern from every stylesheet you own.
2.5.3 — Label in Name
SC 2.5.3
★★★☆☆
MODERATE
For interactive controls with visible text labels, the accessible name must contain the visible text. A button that says "Submit" visually but has aria-label="Send form" does not contain the visible text in its accessible name — failing voice control users who activate controls by saying the visible label.
Principle 3: Understandable
3.1.1 — Language of Page
SC 3.1.1
★★★☆☆
MODERATE
The lang attribute on the <html> element must correctly identify the language of the page content. A French-language page with lang="en" fails — screen readers read the content in the wrong language voice.
3.2.1 — On Focus
SC 3.2.1
★★★☆☆
MODERATE
Moving focus to a component must not trigger an automatic context change. A select element that navigates to a new page when the user arrows through its options fails this criterion.
3.3.1 — Error Identification
SC 3.3.1
★★★★★
HIGH RISK
Form errors must be described in text and associated with the specific input that caused the error. Highlighting a field in red without an error message is non-compliant. The error message must be programmatically associated with the input field so screen readers announce it when the user reaches the field.
3.3.2 — Labels or Instructions
SC 3.3.2
★★★★★
HIGH RISK
All form inputs must have visible labels programmatically associated with them. Placeholder text is not a label — it disappears when the user starts typing and is not reliably announced by all screen readers. Use <label for=""> or aria-labelledby.
3.3.3 — Error Suggestion
SC 3.3.3
★★★★☆
HIGH RISK
When an error is detected, provide a suggestion for correction where known. "Please enter a valid email address" is compliant. "Invalid input" is not.
Principle 4: Robust
4.1.1 — Parsing
SC 4.1.1
★★★☆☆
MODERATE
HTML must be valid: no duplicate IDs, all elements properly nested and closed. Validate at validator.w3.org. Duplicate IDs are the most common parsing failure — they break ARIA associations between labels and inputs.
4.1.2 — Name, Role, Value
SC 4.1.2
★★★★★
HIGH RISK
All UI components must have: an accessible name (via <label>, aria-label, or aria-labelledby); a role (via semantic HTML or explicit role attribute); and appropriate state values (aria-expanded, aria-checked, aria-disabled, aria-required). Custom UI components built without ARIA — dropdown menus, toggle switches, tab panels, accordion widgets — almost always fail this criterion.
4.1.3 — Status Messages
SC 4.1.3
★★★☆☆
MODERATE
Dynamic status messages (form submission confirmations, search result counts, notification banners) must be programmatically determinable via ARIA live regions (aria-live, role="status", role="alert") so screen readers announce them without requiring focus to move to the message.
The 8 Most Commonly Failed Criteria — and What Fixes Each One
In ADA accessibility lawsuits, the same eight failures appear repeatedly. Address these eight and you eliminate the majority of your automated-scan risk.
| Failure | Fix |
|---|---|
| Missing or empty alt text on product/informative images | Add descriptive alt attributes to every informative image; alt="" for decorative images |
outline: none removing focus indicators |
Remove from CSS; replace with a custom visible focus style that meets 3:1 non-text contrast |
Form inputs without associated <label> elements |
Add <label for="input-id"> for every input; never rely on placeholder alone |
| Form error messages not associated with inputs | Add aria-describedby="error-id" on the input linking to the error message element |
| "Read more" / "Click here" link text | Replace with descriptive text or add aria-label="Read more about [topic]" |
| Colour contrast failures on grey text | Check every text/background combination; minimum 4.5:1 for normal text |
| No "Skip to main content" link | Add as the first focusable element; visible on focus |
| Custom UI components without ARIA roles/states | Implement ARIA pattern for each component type (accordion, modal, tab panel, etc.) |
What Accessibility Overlays Actually Do — and Why They Don't Work
Accessibility overlays (accessiBe, UserWay, AudioEye, EqualWeb, and similar products) are JavaScript widgets that inject into a page and attempt to modify it for screen reader compatibility in real-time. They are not a compliance solution.
Warning — Overlays Are Not a Legal Defence
Multiple plaintiffs' firms have successfully argued — and courts have agreed — that a website with an overlay installed is still non-compliant under the ADA if the underlying content is inaccessible. Some demand letters now specifically identify overlay installation as evidence that the defendant was aware of their accessibility obligations but chose a substandard remediation approach — strengthening the case for wilful non-compliance.
The National Federation of the Blind, the American Council of the Blind, and the Disability Rights Advocates organisation have all issued public statements against overlay tools. Users who rely on screen readers have reported that overlays interfere with their existing assistive technology settings.
Overlays do not fix the underlying code. An overlay intercepts screen reader calls but does not change the HTML. The underlying accessibility failures remain. If the overlay fails to load, the website reverts to its inaccessible state.
The only reliable path to WCAG 2.1 AA compliance is fixing the underlying code.
Need a WCAG 2.1 AA Audit?
Our ADA Compliance & Accessibility Audit starts at €490 — with the audit fee credited in full against any remediation project commenced within 60 days. We cover all 50 WCAG 2.1 AA success criteria with a prioritised remediation roadmap.
Western European quality · nearshore price · EU timezone · GDPR-compliant
How to Audit Your Website Right Now — Free Tools
A complete audit requires both automated and manual testing. Automated tools catch approximately 30–40% of WCAG failures. Manual testing is required for the remainder.
Free Automated Tools
- WAVE — browser extension, visual feedback on errors and alerts, good for non-technical users
- Axe DevTools (browser extension, free tier) — more precise than WAVE, fewer false positives, developer-oriented
- Google Lighthouse (built into Chrome DevTools) — accessibility score plus repair guidance; covers roughly 25–30% of WCAG criteria
- Colour Contrast Analyser (free download, TPGi) — precise contrast ratio measurement for any colour pair on screen
Manual Tests No Automated Tool Performs
-
Keyboard navigation test
Navigate your entire website — every page, every form, every dropdown — using only
Tab,Shift+Tab,Enter,Space, and arrow keys. Note anywhere focus becomes invisible, trapped, or jumps unexpectedly. - Screen reader test Install NVDA (free, Windows) or use VoiceOver (built into macOS/iOS). Turn off your monitor. Navigate your homepage, your primary conversion page, and your contact form using screen reader commands only.
- 200% zoom test Set your browser zoom to 200%. Check whether any text overlaps, disappears, or requires horizontal scrolling.
- Mobile touch target test On a mobile device, attempt to tap every interactive element. Any target smaller than approximately 44×44 pixels will be noticeably difficult.
What to Do If Your Website Fails an Audit
If you have received a demand letter
Engage an ADA defence attorney immediately — do not respond to the demand letter yourself. Retain a technical accessibility specialist for an independent audit. The specific WCAG failures alleged in the letter need to be confirmed or disputed by someone qualified to evaluate them. Many demand letters cite failures that exist; some cite failures that are arguable or wrong. You need an independent technical opinion before any settlement discussion.
If your audit reveals failures
Categorise them by priority:
- Critical (high litigation risk): Missing alt text on images, missing form labels, colour contrast failures, no focus indicators, keyboard traps
- Major (significant user impact): No skip navigation, missing error messages, inaccessible custom UI components
- Minor (best practice): Text spacing compliance, status message ARIA, language attributes
Address Critical failures first. Most Critical failures can be remediated in a day of focused development work once they are identified.
For a complete audit with WCAG success criterion mapping and a prioritised remediation roadmap: our Accessibility Audit service starts at €490, with the audit fee credited in full against any remediation project commenced within 60 days.
The SEO Dividend — Why Accessible Websites Rank Better
ADA compliance is not only a legal risk management exercise. Many WCAG 2.1 AA requirements directly overlap with Google's quality signals:
- Descriptive alt text on images → supports Google Image Search indexing and image understanding
- Semantic HTML heading structure → supports content comprehension by Googlebot
- Descriptive link text → reduces ambiguity for crawlers evaluating page relevance
- Fast mobile-optimised pages → improved Core Web Vitals (INP, LCP, CLS)
- Keyboard-navigable, well-structured pages → typically have cleaner DOM structures that crawl more efficiently
langattribute on HTML element → signals content language to Google, supporting correct locale serving
An accessible website is a technically better website — for the 26% of US adults with some form of disability, and for search engine crawlers operating under similar constraints.
Selmir Mujagić
Technical Lead · Hawd Design
Selmir Mujagić is Technical Lead at Hawd Design. He leads technical architecture, code quality standards, and accessibility implementation across all client projects. He writes about web compliance, technical SEO, and development best practices from direct implementation experience — not from documentation. Full biography →