Is Your Website ADA Compliant?

What ADA compliance actually requires for your website

The Americans with Disabilities Act was signed into law in 1990, long before most businesses had websites. Title III of the ADA says that "places of public accommodation" must be accessible to people with disabilities. For years, that meant ramps, elevator buttons with braille, accessible restrooms. Then courts started wrestling with whether websites count as places of public accommodation.

The answer has been yes in virtually every circuit. The first major ruling came in 2017 when the Eleventh Circuit held in Gil v. Winn-Dixie that an inaccessible website violated the ADA. Since then, every federal circuit that has addressed the question has reached the same conclusion, though they differ on the details. Some require a nexus between the website and a physical location. Others (notably the First, Second, and Seventh Circuits) hold that websites are independently covered regardless of whether the business has a physical storefront.

The practical takeaway: if your business is open to the public and has a website, the ADA almost certainly applies to that website. The question isn't whether your site needs to be accessible. It's whether it currently is.

The DOJ's 2024 ruling and what it means

In April 2024, the Department of Justice published a final rule under Title II of the ADA (which covers state and local governments, not private businesses) formally adopting WCAG 2.1 Level AA as the technical standard for government web content. The rule set compliance deadlines: April 2026 for entities with populations of 50,000 or more, and April 2027 for smaller entities.

This rule doesn't directly apply to private businesses. But its impact on private sector litigation has been significant. Before the rule, plaintiff attorneys had to argue that WCAG 2.1 AA was the appropriate standard. Now they can point to the DOJ's own determination and argue that the same standard should logically apply to private businesses too. Courts have been receptive to this argument.

The DOJ also published guidance stating that it "has consistently taken the position that the ADA's requirements apply to all the goods, services, privileges, or activities offered by public accommodations, including those offered on the web." While guidance isn't law, courts give it considerable weight when interpreting the ADA.

What "compliance" actually looks like in practice

There's no ADA compliance certification for websites. No government body issues a stamp of approval. No registry you can join to declare yourself compliant. This is one of the reasons the space is confusing: businesses want a simple answer ("Are we compliant?") and the honest answer is always "it depends on the current state of your site."

What courts look for when evaluating ADA web accessibility claims is whether the website meets WCAG 2.1 Level AA criteria. That standard includes 50 success criteria organized across four principles:

• Perceivable: Users must be able to perceive the content. Images need text alternatives. Videos need captions. Content can't rely on color alone to convey meaning. Text must have sufficient contrast against its background.
• Operable: Users must be able to operate the interface. Everything clickable must be keyboard-accessible. Users need enough time to read and interact with content. Nothing should flash more than three times per second. Navigation must be consistent and predictable.
• Understandable: Content must be readable and predictable. The page language must be declared. Forms must identify errors and suggest corrections. Navigation must be consistent across pages.
• Robust: Content must work with current and future assistive technologies. HTML must be well-formed. Custom components need proper ARIA roles and states. Name, role, and value must be programmatically determinable for all UI components.

Full compliance means meeting all 50 criteria across every page of your site. In practice, most businesses focus on eliminating the high-severity violations first (the ones that actually prevent access) and then work toward comprehensive compliance over time.

The difference between full compliance and reducing risk

Perfect WCAG 2.1 AA compliance across an entire website is a high bar. Large sites with dynamic content, user-generated contributions, third-party integrations, and frequent updates will almost always have some issues at any given moment. Accessibility is a continuous process, not a one-time checkbox.

From a legal risk standpoint, what matters most is demonstrating good faith and eliminating the violations that actually prevent access. Plaintiff attorneys aren't filing lawsuits over minor technical violations that don't affect real users. They're targeting sites where a blind person genuinely can't complete a purchase, a keyboard user gets trapped in a modal dialog, or a screen reader user encounters page after page of unlabeled images and empty buttons.

The practical risk-reduction approach has three layers:

Layer 1: Fix the automated findings. Run an automated scan and fix everything it finds. This covers missing alt text, contrast failures, unlabeled forms, empty links and buttons, missing page language, and broken heading structure. These are the violations most commonly cited in demand letters, and they're the easiest to fix. A developer can usually resolve the automated findings for a small business site in a day or two.

Layer 2: Manual keyboard and screen reader testing. Navigate your most important user flows (homepage, contact form, checkout process, account creation) using only a keyboard. Can you reach and activate every interactive element? Can you tell where the focus is at all times? Then test the same flows with a screen reader. Is every element announced with a meaningful name and role? These tests catch issues that automated tools miss, particularly around custom JavaScript components.

Layer 3: Ongoing monitoring. Set up regular automated scans to catch regressions. Every time someone publishes a blog post without alt text on the hero image, every time a developer adds a form without labels, every time a theme update breaks the heading hierarchy, your monitoring catches it before a plaintiff attorney does. This is what separates businesses that get sued once from businesses that get sued repeatedly.

Actionable steps to get your website ADA compliant

If you're starting from scratch, here's a practical roadmap. This isn't the only way to approach it, but it covers the highest-impact items first and scales from there.

Step 1: Baseline scan

Run an automated accessibility scan on your homepage and your most-visited pages. This gives you a snapshot of where you stand and which issues appear most frequently. Pay attention to the severity levels: critical and serious issues should be fixed first because they represent actual barriers to access.

Step 2: Fix critical and serious violations

Work through the high-severity findings. These typically include images without alt text, form inputs without labels, buttons and links with no accessible name, color contrast failures on body text, and missing page language declarations. Most of these are straightforward HTML fixes. If your site is on a CMS like WordPress, many can be resolved through the admin interface without touching code.

Step 3: Test keyboard navigation

Unplug your mouse and try using your website with only a keyboard. Press Tab to move through interactive elements, Enter or Space to activate them, Escape to close modals or dropdowns. Watch for focus traps (places where Tab stops working), invisible focus (you're tabbing but can't see where you are), and unreachable elements (interactive things you can't get to without a mouse). Fix anything that blocks keyboard-only interaction.

Step 4: Add an accessibility statement

Publish a page on your site that explains your commitment to accessibility, identifies the standard you're targeting (WCAG 2.1 Level AA), provides a way for users to report barriers they encounter, and includes an email address or phone number for accessibility-related requests. This won't prevent a lawsuit on its own, but courts view it favorably as evidence of good faith.

Step 5: Set up ongoing monitoring

Accessibility isn't a project with an end date. Every content update, code change, and plugin installation can introduce new violations. Regular automated scanning catches these regressions early. adaproof monitors your site continuously and alerts you when new issues appear, so you can fix them before they become legal exposure.

Step 6: Consider a professional audit

For sites with complex functionality (custom JavaScript widgets, single-page applications, e-commerce checkout flows, patient portals), a professional accessibility audit fills the gaps that automated tools can't cover. An auditor tests your site with multiple assistive technologies, evaluates the logic and flow of interactive components, and provides specific remediation guidance. Typical cost: $2,000 to $10,000 depending on site complexity.

Frequently asked questions

Related tools: Home · ADA compliance checker · WCAG compliance checker · Website accessibility checker · Accessibility audit · ADA compliance for ecommerce · ADA compliance for small business