Website Not ADA Compliant: Risks, Requirements, and How to Fix It

A website that is not ADA compliant puts up barriers that stop people with disabilities from using it: missing alt text on images, keyboard traps that lock users out of the navigation, contrast so low the text is unreadable. These are not cosmetic details. They are the digital version of a storefront with a staircase and no ramp, and they can breach the Americans with Disabilities Act the same way.

The scale is large. About one in four US adults has a disability that affects how they use the web, and roughly 1.3 billion people worldwide have disabilities that call for accessible digital services. More than 4,600 ADA website lawsuits were filed in 2025, and 2026 is on track to be higher. An inaccessible site is both a legal exposure and a wall between you and a real slice of your audience.

This guide covers when the ADA applies to your site and which titles matter, the failures that trigger lawsuits, how demand letters actually work, and a practical roadmap for fixing the problems and reducing your exposure.

When does the ADA apply to websites and apps?

Two parts of the Act reach websites directly. Title II covers state and local governments and requires their digital services to be accessible. Title III bars discrimination by public-facing businesses and covers “places of public accommodation,” a category courts and the Department of Justice have repeatedly extended to websites, web apps, and mobile apps.

The 1990 ADA text predates the modern web and never names it, but the DOJ and federal agencies read online services as part of the covered activities. Enforcement actions now consistently point to WCAG 2.1 Level AA as the yardstick for whether web content measures up. In practice:

• Ecommerce shops, retailers, restaurants, hospitals, banks, and universities are usually places of public accommodation under Title III.
• State and local government portals for permits, taxes, and licensing fall under Title II.
• If the ADA applies to your physical location, it almost certainly applies to your website too, a restaurant’s online ordering has to be as usable as its front counter.
• Federal agencies carry separate obligations under the Rehabilitation Act, but the practical bar is similar.

The law here keeps moving, so any business open to the public should treat accessibility as a standing obligation rather than a one-off task.

Title II deadlines for state and local governments

The DOJ’s Title II final rule formally adopts WCAG 2.1 Level AA as the standard for state and local government websites and mobile apps, turning what was implied into an explicit requirement.

• Governments serving populations of 50,000 or more must comply by April 26, 2027.
• Smaller entities and special district governments have until April 26, 2028.
• Scope covers public-facing sites, public-used staff portals, and apps for paying taxes, renewing licenses, and reporting issues.

After those dates, a non-compliant site at a city, county, or school district can invite DOJ enforcement, private complaints, and consent decrees, and documented failure past the deadline leaves little to defend. Public entities should fix the highest-impact services first: emergency and police/fire information, benefits applications and online forms, council-meeting recordings with synchronized captions, and PDFs that work by keyboard and screen reader. Narrow exceptions exist for genuinely archived, unchanged legacy documents, but anything in active use or recently updated has to meet the standard.

Do private business websites have to comply?

In most jurisdictions, yes, private businesses serving the public are expected to meet ADA standards, and courts in New York, California, and Florida have been especially aggressive, treating websites as extensions of physical locations or as public accommodations in their own right.

The landmark case is Robles v. Domino’s Pizza (Ninth Circuit, 2019). Guillermo Robles, who is blind, alleged that Domino’s website and app were unusable with a screen reader and blocked him from ordering. The court confirmed ADA coverage for websites under Title III, and Domino’s settled in 2022, committing to WCAG conformance and internal accessibility training.

What makes a website “not compliant”? The common barriers

An inaccessible site stops people with disabilities from perceiving, operating, or understanding content through assistive technology like screen readers, refreshable Braille displays, or voice control. WCAG sorts the failures into four principles, Perceivable, Operable, Understandable, Robust.

Perceivable failures are the most common. Images need text alternatives, yet missing alt text showed up in about 89% of complaint cases in 2025. Contrast has to clear a minimum, and poor contrast was cited in roughly 68% of cases. Video needs captions and audio needs transcripts, including synchronized captions for pre-recorded media.

Operable failures include menus and form fields that a keyboard alone can’t work, keyboard traps that strand users inside a widget, and auto-rotating carousels with no pause control. Keyboard failures appeared in about 61% of cases, and keyboard access is essential for people with motor or cognitive disabilities.

Understandable failures cover inconsistent navigation, unclear form errors, session timeouts with no warning, and instructions that lean only on color or shape (“click the green button”), which shuts out people who can’t perceive color. Text that won’t resize and reflow is another frequent gap.

Robust failures come from broken HTML structure, misused ARIA attributes, and components with no programmatically determinable name or role. These confuse screen readers and break assistive-tech compatibility, and they do as much damage as the visible problems. Concrete examples: a checkout button with no accessible label, a PDF menu a screen reader can’t read, a CAPTCHA with no accessible alternative, or a call-to-action with too little contrast, any one of which can block an entire transaction.

Lawsuit and demand-letter risk

ADA website lawsuits climbed from roughly 800 filings in 2018 to over 5,100 in federal court in 2025, with 2026 projections in the 7,000–8,500 range, and thousands more unfiled demand letters circulate every year. The pattern is consistent: plaintiff firms scan sites with automated checkers, and when they find WCAG failures they send a letter citing specific criteria (1.1.1 for text alternatives, 2.1.1 for keyboard access), referencing Title III, and asking for remediation plus fees and damages.

• Settlements for small and mid-sized businesses typically run $5,000 to $50,000+, on top of remediation costs.
• Higher-risk targets: ecommerce, restaurants, hotels, healthcare portals, education platforms, and any site with logins or complex forms.
• Filings tend to reference the same cluster of WCAG criteria, which makes the exposure predictable.
• “Accessibility overlay” widgets have themselves drawn lawsuits, because they rarely fix the underlying code.
• Cases concentrate in New York, California, and Florida, but no state is immune.

A site that conforms to WCAG 2.1 AA holds a strong legal position; one that ignores accessibility is an easy target.

The standard: WCAG 2.1 and 2.2

The Web Content Accessibility Guidelines, from the World Wide Web Consortium (W3C), are the de facto technical benchmark for ADA website compliance, and the reference in nearly every settlement and DOJ action. WCAG has three conformance levels:

• Level A, the most fundamental, blocking issues such as alt text and keyboard access. Miss these and you create major barriers.
• Level AA, the standard for ADA compliance: color contrast (at least 4.5:1 for normal text), visible focus, form labeling, and error handling.
• Level AAA, advanced criteria that the law rarely mandates.

Most settlements and DOJ agreements cite WCAG 2.1 AA. Newer contracts and some plaintiffs are starting to reference WCAG 2.2, published in October 2023, which adds criteria for focus appearance, dragging movements, target size, and accessible authentication. And compliance is not just passing an automated scan: tools catch roughly 25% of accessibility issues, and the rest need manual testing and real user feedback.

How to check whether your site complies

Use a layered workflow, automated tools, manual testing, and testing with people who have disabilities.

Automated scanning is the fast first pass. Axe, WAVE, and Lighthouse flag machine-detectable problems, missing alt attributes, low contrast, empty links, broken heading order. Treat them like a spell-checker for accessibility: useful, nowhere near complete.

Manual testing is where you catch what automation can’t, whether alt text is actually meaningful, whether a widget traps focus, whether an error message makes sense:

• Navigate the whole site with the keyboard only (Tab, Shift+Tab, Enter, Space, arrows) to check focus order and hunt for traps.
• Test with a screen reader, NVDA or JAWS on Windows, VoiceOver on macOS/iOS, to confirm menus, forms, dialogs, and errors are announced correctly.
• Confirm every interactive element is reachable and operable without a mouse.

User testing with people who have visual, motor, and cognitive disabilities surfaces real-world gaps that neither tools nor developers will predict. For complex or high-risk sites, online banking, healthcare, education, bring in accessibility experts for a professional audit mapped to WCAG 2.1 or 2.2 AA. Document what you find, prioritize by severity, fix, and retest.

Fixing it: a practical remediation roadmap

Making a site accessible is a phased process, not a single project, and a lot of the work improves usability for everyone, so it pays off beyond compliance.

• Phase 1, triage. Use the audit to find the high-severity barriers blocking core tasks, logging in, checking out, booking, submitting a contact form, and fix those first. A checkout that can’t be completed by keyboard outranks a blog image with no description.
• Phase 2, structural fixes. Correct the semantic HTML so headings, lists, landmarks, and form labels are coded properly. Make menus, modals, carousels, and custom widgets keyboard-operable. Raise contrast and add visible focus states across the design system.
• Phase 3, content and media. Add accurate alt text to meaningful images and mark decorative ones as such. Caption video and add audio descriptions where needed. Replace vague link text like “click here” with something descriptive, and check every form field for proper labels and accessible error messages.
• Phase 4, ongoing governance. Write internal accessibility guidelines for editors, designers, and developers, and require an accessibility review on every redesign, plugin change, or new feature. It’s a maintenance commitment, not a finish line.

One caution: an “accessibility overlay” widget on its own is not enough. Courts have repeatedly found overlays don’t resolve the underlying code and structure. The real fix lives in the code and content.

Reducing lawsuit risk: policy, documentation, statements

No policy guarantees immunity, but documented good-faith effort meaningfully lowers your risk and strengthens a defense.

Adopt an internal accessibility policy that commits to WCAG 2.1 AA now with a plan to move to 2.2 AA, assigns responsibility to specific teams (product, IT, content), and requires an accessibility review before any launch.

Publish an accessibility statement that describes your goals and current status, names the standard you’re working toward, and gives a clear contact, email and/or phone, for people to report problems or ask for help. A statement with no real evaluation behind it is weak evidence; paired with documented audits, completed fixes, and ongoing monitoring, it shows genuine commitment.

Keep records. Hold onto audit reports, remediation plans, training materials, and the dates of major improvements. If a demand letter or investigation ever arrives, that trail shows continuous progress instead of neglect.

For small businesses: costs, credits, and steps

The fear of a surprise demand letter is real, and small businesses get sued for inaccessible sites just like large ones, but the path to compliance doesn’t have to be expensive. A site under 50 pages can often reach WCAG 2.1 AA by focusing on templates, navigation, forms, and media rather than editing page by page:

• Fix keyboard and screen-reader barriers on navigation and the checkout or booking flow.
• Ensure sufficient contrast and visible focus indicators across the theme.
• Add alt text, form labels, and accessible error messages.
• Choose accessible themes and plugins from the start, and require accessibility from vendors.

Turning a non-compliant site into an accessible asset

An inaccessible website blocks millions of users, raises your lawsuit risk, and erodes trust. The path forward is straightforward: work out whether Title II or Title III applies to you, evaluate the site against WCAG 2.1 AA with both automated and manual testing, fix the high-impact barriers first, then put ongoing governance in place.

The payoff runs past legal protection. Accessibility improvements strengthen SEO through cleaner semantic structure, alt text, and heading hierarchy; they help on mobile and for people with temporary impairments, a broken arm, bright sun, a noisy room; and they widen your audience. With Title II deadlines landing in 2027 and 2028 and lawsuit counts still climbing, waiting for a demand letter is the most expensive option. Run a scan this week, document what you find, and start an accessibility statement backed by real remediation, because equal access is both the law and the way you build something that works for everyone.