What Is ADA Compliance?

What the ADA Actually Requires

The Americans with Disabilities Act was signed into law in 1990 to prohibit discrimination against people with disabilities. It is divided into five titles, each covering a different area of public life.

The Five Titles of the ADA

• Title I — Employment: Prohibits discrimination in hiring, promotion, and workplace accommodations.
• Title II — State and Local Government: Requires government services, programs, and activities to be accessible, including websites.
• Title III — Public Accommodations: Requires businesses open to the public to be accessible. This is the title that applies to most commercial websites.
• Title IV — Telecommunications: Requires telephone and internet companies to provide relay services.
• Title V — Miscellaneous: Covers technical provisions, relationship to other laws, and retaliation protections.

Title II vs Title III: Which Applies to You?

Title II applies to state and local government entities — city websites, public university portals, DMV systems, public transit apps. In April 2024, the Department of Justice published a final rule explicitly requiring government websites to meet WCAG 2.1 Level AA.

Title III applies to private businesses that are “places of public accommodation.” This includes restaurants, hotels, retail stores, healthcare providers, banks, law firms, and virtually any business with a public-facing website. While Title III does not explicitly mention websites, the DOJ has consistently interpreted it to cover digital properties, and federal courts — including the First, Second, Seventh, and Ninth Circuits — have upheld this interpretation.

Who Must Comply (and the Myths)

A common misconception is that ADA web compliance only applies to large corporations or government agencies. This is false. The ADA applies to all businesses that serve the public, regardless of size, revenue, or industry. A five-person law firm with a brochure website has the same legal obligation as Amazon.

Another myth: that you only need an accessible website if you sell products online. Courts have ruled that even informational websites — those that simply describe your business, list your services, or provide directions to your physical location — must be accessible because they function as an extension of your place of public accommodation.

A third myth: that compliance is only required if you have disabled customers. The ADA is a proactive law. You must be accessible before someone with a disability tries to use your website, not after they file a complaint.

WCAG 2.1 and 2.2 — The Technical Standard

The Web Content Accessibility Guidelines (WCAG) are published by the World Wide Web Consortium (W3C) and define the technical requirements for accessible web content. WCAG is not law itself — it is the standard that courts, regulators, and accessibility professionals reference when evaluating whether a website is compliant.

The Four POUR Principles

Every WCAG requirement falls under one of four principles:

• Perceivable: Information must be presentable in ways users can perceive. This means providing text alternatives for images, captions for video, and sufficient color contrast. A blind user relying on a screen reader cannot perceive an image without alt text.
• Operable: Interface components must be operable by all users. Every function must work with a keyboard alone — no mouse required. Links must have visible focus indicators. Users must have enough time to read and interact with content.
• Understandable: Content must be readable and predictable. Forms must provide clear labels and error messages. Navigation must be consistent across pages. The page language must be declared in the HTML.
• Robust: Content must be compatible with current and future assistive technologies. This means using semantic HTML, valid markup, and proper ARIA attributes where native elements are insufficient.

Conformance Levels: A, AA, and AAA

WCAG defines three levels of conformance:

• Level A — the bare minimum. Covers the most basic requirements like alt text for images and keyboard operability. Meeting only Level A leaves significant accessibility gaps.
• Level AA — the standard. This is the level that courts, regulators, and the DOJ reference for ADA compliance. It adds requirements for color contrast, text resizing, consistent navigation, and form error identification. This is your target.
• Level AAA — the gold standard. Adds requirements like sign language interpretation for video, enhanced contrast ratios, and extended audio descriptions. Most organizations do not target full AAA conformance, but implementing select AAA criteria where practical is a best practice.

WCAG 2.1 vs 2.2: What Changed

The 15 Most Critical Website Accessibility Fixes

These fifteen issues account for the vast majority of accessibility barriers on the web. Fix these and you address roughly 80% of the problems that real users encounter and that auditors flag.

1. Add Alt Text to Every Image

Screen readers announce images by reading their alt attribute. Without alt text, a blind user hears “image” or nothing at all. Decorative images should use an empty alt="" to be skipped entirely.

<!-- Bad -->
<img src="team-photo.jpg">

<!-- Good -->
<img src="team-photo.jpg" alt="The Grow Wild team at our Vancouver office">

<!-- Decorative image -->
<img src="divider-line.svg" alt="" role="presentation">

2. Ensure Full Keyboard Navigation

Every interactive element — links, buttons, forms, menus, modals — must be operable using only a keyboard. Users who cannot use a mouse rely on Tab, Shift+Tab, Enter, Space, Escape, and arrow keys to navigate. Test by unplugging your mouse and navigating your entire site.

3. Meet Color Contrast Ratios

Normal text (under 18px) requires a 4.5:1 contrast ratio against its background. Large text (18px bold or 24px regular) requires 3:1. Light gray text on white backgrounds is the single most common contrast failure on the web.

<!-- Fails: #999 on #fff = 2.85:1 -->
<p style="color: #999">This text fails contrast.</p>

<!-- Passes: #595959 on #fff = 7:1 -->
<p style="color: #595959">This text passes contrast.</p>

4. Use Proper Heading Hierarchy

Headings (<h1> through <h6>) create a document outline that screen reader users navigate like a table of contents. Never skip heading levels (for example, jumping from <h2> to <h4>). Use only one <h1> per page. Do not use headings purely for visual styling.

5. Label All Form Inputs

Every form field must have a visible <label> element programmatically associated with the input via for and id attributes. Placeholder text is not a substitute for labels — it disappears when users begin typing and is not reliably announced by all screen readers.

<!-- Bad: placeholder as label -->
<input type="email" placeholder="Your email">

<!-- Good: proper label -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" autocomplete="email">

6. Provide Captions and Audio Descriptions for Video

Pre-recorded video must have synchronized captions for deaf and hard-of-hearing users. Audio descriptions (a narration track describing visual content) are required for blind users. Auto-generated captions are a start, but they must be reviewed and corrected for accuracy.

7. Use Semantic HTML Structure

Use <nav> for navigation, <main> for primary content, <header> and <footer> for their respective purposes, <article> for self-contained content, and <section> for thematic groupings. These landmarks allow screen reader users to jump directly to the content they need instead of tabbing through every element.

8. Add a Skip Navigation Link

The first focusable element on every page should be a “Skip to main content” link that jumps past the navigation. Without it, keyboard users must tab through every navigation link on every page before reaching the content.

<body>
  <a href="#main-content" class="skip-link">Skip to main content</a>
  <header>...navigation...</header>
  <main id="main-content">...content...</main>
</body>

9. Make Focus Indicators Visible

When a user tabs to an interactive element, that element must have a clearly visible focus indicator — typically an outline. Never use outline: none without providing an alternative focus style. WCAG 2.2 adds specific requirements for focus indicator size and contrast.

10. Implement Accessible Error Handling

Form validation errors must be identified in text (not just by color), associated with the field that caused the error, and announced to screen readers. The error message should describe the problem and suggest how to fix it.

11. Use Descriptive Link Text

Links must make sense out of context. Screen reader users often navigate by listing all links on a page. “Click here” and “Read more” are meaningless without surrounding text. Write links that describe the destination: “View our case studies” or “Download the accessibility checklist.”

12. Size Touch Targets Appropriately

Interactive elements must be large enough to tap accurately. WCAG 2.2 Level AA requires a minimum target size of 24×24 CSS pixels. Best practice (AAA) is 44×44px. Small links, close buttons, and icon-only buttons are frequent offenders.

13. Do Not Use Color Alone to Convey Information

If you use red to indicate an error, you must also use an icon, text, or pattern. Approximately 8% of men and 0.5% of women have some form of color vision deficiency. A red asterisk alone to mark required fields fails this criterion.

14. Make Dynamic Content Accessible

Content that updates dynamically — live search results, shopping cart totals, notification banners, chat widgets — must be announced to screen readers using ARIA live regions (aria-live="polite" or aria-live="assertive"). Without this, screen reader users never learn that content has changed.

15. Ensure Accessible Documents

PDFs, Word documents, and spreadsheets linked from your website must also be accessible. This means tagged PDFs with proper reading order, alt text on embedded images, and table headers. If you cannot make a PDF accessible, provide the same content in an accessible HTML alternative.

Why Accessibility Overlays Will Not Protect Your Business

Accessibility overlays are JavaScript widgets — typically a toolbar icon in the corner of a website — that claim to make websites ADA compliant automatically. Companies like accessiBe, AudioEye, UserWay, and EqualWeb market these products as quick, affordable alternatives to manual remediation. They do not work, and they are making the problem worse.

The FTC’s $1 Million Fine Against accessiBe

In April 2025, the Federal Trade Commission fined accessiBe $1 million for deceptive marketing practices. The FTC found that accessiBe’s claims of automated ADA compliance were “false and unsubstantiated.” The company had marketed its AI-powered overlay as a solution that could make any website fully compliant within 48 hours. Independent testing consistently showed that accessiBe-equipped sites still contained dozens of accessibility barriers.

Overlays Are Named in Lawsuits

Rather than preventing lawsuits, overlays are increasingly cited as evidence of insufficient effort. Data from accessibility litigation tracking shows that over 25% of ADA web accessibility lawsuits in 2024 targeted websites using overlay products. Plaintiff attorneys have described overlays as “low-hanging fruit” because they demonstrate that a business was aware of its accessibility obligations but chose a shortcut instead of genuine remediation.

Why Overlays Fail Technically

• AI cannot infer intent. An overlay can detect that an image lacks alt text, but it cannot determine what the image depicts. AI-generated alt text is frequently inaccurate, generic, or misleading.
• Overlays cannot fix source code. They add a JavaScript layer on top of broken HTML. The underlying accessibility problems remain, and screen readers interact with the source code, not the overlay.
• They create new barriers. Overlay widgets can interfere with existing assistive technology settings, override user preferences, and introduce keyboard traps where none existed before.
• They fail on dynamic content. Single-page applications, JavaScript-rendered content, and client-side routing are invisible to overlay scripts that run on initial page load.

The Professional Consensus

The disability community and accessibility professionals have been unequivocal: overlays are harmful. The National Federation of the Blind has publicly opposed overlay products. The American Bankers Association has warned member institutions against relying on overlays. Over 700 accessibility professionals have signed an open letter opposing overlay products at overlayfactsheet.com.

What to Do If You Currently Use an Overlay

1. Remove the overlay script from your website immediately.
2. Run a manual accessibility audit to identify actual barriers.
3. Prioritize fixes by severity (critical barriers first).
4. Fix issues in your source code, not with a JavaScript Band-Aid.
5. Test with real assistive technology (screen readers, keyboard navigation).

ADA Web Accessibility Lawsuits in 2025–2026

ADA web accessibility litigation has grown steadily over the past decade and shows no signs of slowing. Understanding the data helps you assess your own risk and justify the investment in proper remediation.

The Numbers

• 4,000+ lawsuits were filed in the United States in 2024 alone.
• This represents a 15% year-over-year increase from 2023.
• New York and California account for approximately 80% of all filings.
• The average time from demand letter to settlement is 4–8 months.
• 95%+ of cases settle out of court — they rarely go to trial.

Industries Most Targeted

The Real Cost of Non-Compliance

A lawsuit is not just a settlement payment. The total cost includes:

• Legal fees: $10,000–$50,000+ for defense, even if you settle.
• Settlement payment: $25,000–$100,000+ depending on the scope and plaintiff’s demands.
• Remediation costs: You still have to fix the site after settling, typically under court-mandated timelines.
• Monitoring agreement: Many settlements require ongoing accessibility monitoring for 2–3 years at $500–$2,000 per month.
• Repeat litigation: Serial plaintiffs can file again if issues recur. About 20% of defendants are sued more than once.
• Reputation damage: Lawsuits become public record. Clients, partners, and prospects will find them.

How to Reduce Your Risk

1. Fix the obvious issues now. The fifteen fixes listed above address the most commonly cited violations.
2. Publish an accessibility statement. A genuine statement that acknowledges your commitment, describes your current conformance level, and provides a contact for reporting issues demonstrates good faith.
3. Document your efforts. Keep records of audits, fixes, and testing. Courts view documented, ongoing effort favorably — even if your site is not yet perfect.
4. Respond to demand letters promptly. Many cases escalate because businesses ignore the initial letter. A prompt, good-faith response can often resolve the matter before litigation.
5. Engage a professional. An accessibility-focused ADA web design and accessibility partner can identify and fix issues faster than internal teams who lack accessibility expertise.

If You Are in Canada

Canada has its own accessibility legislation at both the federal and provincial levels. If your business operates in Canada — or serves Canadian customers from the United States — you need to understand these requirements alongside the ADA.

Accessible Canada Act (Federal)

The Accessible Canada Act (ACA) came into force in 2019. It applies to federally regulated organizations including banks, telecommunications companies, transportation providers, and the federal government itself. The ACA requires these organizations to identify, remove, and prevent accessibility barriers across their operations — including digital content. Regulations are still being developed, but WCAG 2.1 AA is the expected standard.

Accessible British Columbia Act

British Columbia passed its accessibility legislation in 2021 with the Accessible British Columbia Act. The province is developing specific accessibility standards for areas including information and communications technology. While detailed web accessibility standards are still being finalized, businesses in BC should prepare by targeting WCAG 2.1 AA. For Vancouver-based businesses, proactive compliance positions you ahead of enforcement.

AODA (Ontario)

Ontario’s Accessibility for Ontarians with Disabilities Act (AODA) is the most mature provincial framework. Since January 2021, all organizations with 50+ employees in Ontario must make their websites and web content conform to WCAG 2.0 Level AA. Non-compliance can result in fines of up to $100,000 per day for corporations.

ADA vs Canadian Law: Comparison

How to Make Your Website Accessible: The Remediation Roadmap

Accessibility remediation is not a one-time project — it is an ongoing practice. But it starts with a structured process. Here is the six-step roadmap we use with our clients.

Step 1: Run a Comprehensive Audit

Start with automated testing tools — axe DevTools, WAVE, or Google Lighthouse — to identify the low-hanging fruit. Automated tools catch approximately 30–40% of accessibility issues. The remaining 60–70% require manual testing.

Your manual audit should include:

• Keyboard-only navigation through every page and interactive element.
• Screen reader testing (VoiceOver on Mac, NVDA on Windows) on key user journeys.
• Color contrast verification using a tool like the WebAIM Contrast Checker.
• Heading structure analysis to verify proper hierarchy.
• Form testing to verify labels, error handling, and validation messages.

Step 2: Prioritize by Severity and Impact

Not all issues are equal. Prioritize using this framework:

1. Critical (fix immediately): Barriers that prevent users from accessing core functionality — no keyboard navigation, missing form labels on checkout, no alt text on primary content images.
2. High (fix within 30 days): Issues that significantly degrade the experience — insufficient contrast on body text, missing skip navigation, focus traps in modals.
3. Medium (fix within 90 days): Issues that create friction but do not block access — decorative images missing alt="", inconsistent heading levels in blog posts, missing language attributes on foreign-language content.
4. Low (fix within 6 months): Enhancements that improve the experience — ARIA landmark refinements, enhanced touch target sizes, improved error message specificity.

Step 3: Fix the Source Code

Accessibility fixes must be made in the source code, not through overlays or workarounds. This means working directly in your CMS templates, theme files, component libraries, and page content. Common areas that need attention:

• HTML templates (heading structure, semantic elements, landmark roles)
• CSS (contrast, focus indicators, visibility, responsive behavior)
• JavaScript (keyboard event handlers, ARIA state management, focus management)
• CMS content (alt text, heading usage, link text, table markup)
• Third-party widgets (chatbots, analytics overlays, cookie banners, embedded forms)

Step 4: Test with Assistive Technology

After fixes are implemented, test again. The most reliable testing involves:

• Screen readers: VoiceOver (Mac/iOS), NVDA (Windows, free), JAWS (Windows, paid). Test the top three to five user journeys.
• Keyboard only: Can you complete every task without a mouse? Is the focus indicator always visible?
• Zoom to 200%: Does content reflow without horizontal scrolling? Are touch targets still reachable?
• Browser extensions: axe DevTools and WAVE for automated re-verification.

Step 5: Publish an Accessibility Statement

An accessibility statement is a public declaration of your commitment to accessibility. It should include:

• Your conformance target (e.g., WCAG 2.1 Level AA).
• Known limitations or areas still being remediated.
• A contact method for reporting accessibility barriers (email, phone, or form).
• The date the statement was last reviewed.

This statement serves both as a good-faith signal to regulators and as a practical resource for users who encounter barriers. It does not need to be long — clarity and honesty matter more than length.

Step 6: Establish Ongoing Monitoring

Accessibility is not a one-time checkbox. New content, design updates, third-party widget changes, and CMS upgrades can all introduce new barriers. Ongoing monitoring should include:

• Automated scanning: Run weekly or monthly scans using tools like axe Monitor, Siteimprove, or Deque.
• Manual spot checks: Test new pages and features before they launch.
• Training: Ensure content editors understand alt text, heading hierarchy, and link text best practices.
• Quarterly reviews: Audit a sample of pages each quarter to catch regression.

Our team is trained in the same federal accessibility frameworks we help you implement. These certifications are from GSA Section508.gov and the U.S. Department of Homeland Security.

View all 17 certifications including Customer Experience and Usability Testing credentials.

Frequently Asked Questions