ADA Website Compliance: The Complete 2026 Guide

Website accessibility is no longer optional for most businesses. The Americans with Disabilities Act (ADA) applies to places of public accommodation—and courts have consistently held that websites qualify. Whether you run an e-commerce store, a SaaS platform, a professional services firm, or a local business website, understanding what ADA website compliance means in practice is the first step toward reducing risk and improving your site for all users.

This guide explains what ADA website compliance means, how WCAG connects to legal risk, what automated accessibility scans can and cannot find, and what steps your team should take after an audit.

What ADA Website Compliance Means

The ADA was signed into law in 1990, before the modern web existed. It does not contain a specific technical checklist for websites. What it does require is that businesses covered under Title III—places of public accommodation—do not discriminate against people with disabilities.

Because the ADA has no built-in web standard, courts, the Department of Justice (DOJ), and plaintiff attorneys have looked to the Web Content Accessibility Guidelines (WCAG) as the practical benchmark for determining whether a website is accessible. The DOJ formally endorsed WCAG 2.1 Level AA in its 2024 rulemaking for state and local government websites under Title II, reinforcing WCAG’s role as the de facto standard.

In practice, “ADA website compliance” typically means your website meets or substantially meets WCAG 2.1 or WCAG 2.2 Level AA criteria.

How WCAG Connects to ADA Risk

WCAG is organized around four principles: Perceivable, Operable, Understandable, and Robust (POUR). Each principle contains specific success criteria rated at Level A, AA, or AAA. For ADA compliance purposes, Level AA is the standard teams use.

WCAG 2.1 added criteria for mobile accessibility and cognitive considerations. WCAG 2.2, finalized in 2023, added criteria around focus visibility, dragging alternatives, and target size—all areas that affect real users and appear in audit findings.

When a plaintiff or demand letter targets a website, they typically cite specific WCAG failures as evidence of discrimination. Common examples include missing alternative text on product images, inaccessible checkout forms, and keyboard-blocking navigation. Fixing these WCAG failures is both the practical and legal path forward.

What Automated Scans Can Find

Automated accessibility scans analyze your website’s code and rendered output to flag WCAG violations that can be detected programmatically. A quality automated scan can reliably identify:

• Missing or empty alt text on images, including decorative images that should have empty alt attributes
• Insufficient color contrast between text and background, including large text and interactive elements
• Missing form labels on input fields, dropdowns, checkboxes, and radio buttons
• ARIA misuse such as invalid roles, missing required ARIA attributes, or conflicting labels
• Heading structure problems including skipped heading levels and missing page-level headings
• Keyboard traps and missing focus indicators on interactive elements
• Missing language attributes on the HTML element
• Inaccessible document titles and missing landmark regions
• Empty links and buttons without accessible names

Automated scans are fast, repeatable, and can cover your entire site at scale. They are the right first step for any accessibility program.

What Automated Scans Cannot Prove

Automated scanning covers an estimated 30–40% of WCAG success criteria. The rest requires human judgment. Scans cannot reliably determine:

• Whether alt text is meaningful and accurately describes image content
• Whether keyboard navigation order makes logical sense to a user
• Whether instructions rely solely on sensory characteristics like color or position
• Whether complex interactions like sliders, carousels, or custom widgets are operable with assistive technology
• Whether video content has accurate captions and audio descriptions
• Whether content is cognitively accessible for users with reading or attention difficulties

A passing automated scan does not equal ADA compliance. It means your site passed the checks that can be automated—an important baseline, not a legal certification. Manual testing with assistive technologies such as screen readers (NVDA, JAWS, VoiceOver) is still necessary for a complete audit.

Common ADA Website Compliance Issues

Across millions of scanned pages, these are the most frequently detected accessibility failures:

Color Contrast

WCAG 2.1 SC 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Low contrast affects users with low vision and anyone in bright ambient lighting. This failure appears on a high percentage of websites, often in navigation menus, footer text, placeholder text, and disabled form elements.

Missing Alt Text

Images without alt text are invisible to screen reader users. Informative images need descriptive alt text. Decorative images need an empty alt attribute (alt="") to be skipped by assistive technology. CMS-generated images, social media embeds, and third-party widgets are common sources of this failure.

Keyboard Navigation

All functionality must be operable via keyboard alone. Custom dropdowns, modal dialogs, date pickers, and tab panels are frequent offenders. Users who rely on keyboard navigation include people with motor disabilities, power users, and switch access users.

Form Accessibility

Form inputs must have programmatically associated labels. Placeholder text does not substitute for a label. Error messages must be descriptive and associated with the relevant field. Contact forms, checkout flows, and subscription forms are high-risk areas for form accessibility failures.

Heading Structure

Headings create the document outline that screen reader users navigate. Skipping heading levels (jumping from H2 to H4), using headings purely for visual styling, or having no H1 on a page all create navigation barriers.

Interactive Components

Carousels, accordions, tabs, tooltips, and modal dialogs must follow ARIA authoring practices to be accessible. Many third-party widgets and page builder components fail these requirements out of the box.

What to Do After a Scan

Running a scan is the start of the process, not the end. Here is what a practical remediation workflow looks like:

1. Prioritize by impact and frequency. Fix failures that affect the most pages and the highest-traffic user flows first. A broken checkout form is higher priority than a contrast issue on a rarely-visited policy page.
2. Assign to development. Create tickets in your project management system with specific WCAG criteria, affected elements, and remediation guidance. Vague tickets (“fix accessibility”) produce inconsistent results.
3. Conduct manual testing. After automated fixes, test critical flows with a screen reader and keyboard-only navigation. Identify issues automated tools cannot find.
4. Document your work. Keep records of what was scanned, what was found, what was fixed, and when. Documentation demonstrates good faith effort, which matters in legal contexts.
5. Set up ongoing monitoring. Accessibility regressions are common during site updates, new feature launches, and CMS content changes. Automated monitoring catches new issues before they accumulate.
6. Consider an accessibility statement. Publishing an accessibility statement signals commitment, provides a feedback channel for users with disabilities, and demonstrates proactive intent.

ADA Website Compliance Checklist

Use this checklist as a starting point for your accessibility review:

• Run an automated scan across all key page templates (homepage, product/service pages, contact, checkout)
• Verify all images have meaningful alt text or empty alt attributes
• Check color contrast across text, buttons, links, and form elements
• Test all forms for programmatically associated labels and accessible error messages
• Navigate all pages and interactive elements using keyboard only
• Verify heading structure creates a logical document outline on every page
• Test with a screen reader on critical user flows
• Review any third-party widgets, embeds, and plugins for accessibility
• Check that video content has accurate captions
• Confirm skip navigation links are present and functional
• Publish or update your accessibility statement
• Set up monitoring to catch regressions after future site updates

Frequently Asked Questions

Does the ADA require my website to be WCAG compliant?

The ADA does not explicitly name WCAG in its text, but courts and the DOJ have treated WCAG 2.1 Level AA as the practical standard for website accessibility. Meeting WCAG 2.1 or 2.2 AA significantly reduces your legal exposure and is the most defensible position.

What businesses are covered by the ADA for websites?

Title III of the ADA covers places of public accommodation, which courts have broadly interpreted to include commercial websites. Businesses with physical locations that also operate a website, as well as pure-play online businesses, have both faced ADA website lawsuits. The safest assumption is that if you operate a commercial website serving US customers, the ADA applies.

Can I get sued even if my website mostly passes an automated scan?

Yes. Automated scans only cover a portion of WCAG criteria. A site can pass automated checks and still have meaningful barriers for screen reader users or keyboard-only users. Manual testing is an important part of a complete accessibility program.

How long does it take to make a website ADA compliant?

Timeline varies significantly by site complexity. A simple informational website with disciplined HTML might need only a few days of remediation. A large e-commerce platform with custom components, third-party integrations, and a large content library could require months of phased work. Starting with automated scanning to scope the problem is always the right first step.

Does adding an accessibility overlay make my site ADA compliant?

Accessibility overlays—JavaScript widgets that attempt to fix accessibility issues at the UI layer—do not achieve WCAG compliance. Disability advocacy organizations, accessibility researchers, and the US Access Board have published statements explaining why overlays are not a substitute for genuine remediation. Overlays may also interfere with the assistive technologies users already have configured. Building accessibility into the codebase is the only durable solution.

What is the European Accessibility Act and does it affect US businesses?

The European Accessibility Act (EAA) requires digital products and services offered to EU consumers to meet EN 301 549 accessibility standards (which reference WCAG 2.1 AA). If your business sells to EU customers—including via e-commerce—you may have EAA obligations in addition to ADA considerations. The EAA compliance deadline for most covered entities was June 28, 2025.