ADA Website Lawsuits: Scope, Barriers, and Practical Next Steps

ADA Website Lawsuits: Scope, Barriers, and Practical Next Steps

An inaccessible website can prevent someone from buying a product, booking an appointment or using a service. An automated scan can identify some technical barriers, but cannot predict a lawsuit, its cost or its outcome. This guide provides general information and practical testing steps, not advice about a particular legal claim.

What Does the ADA Require for Websites?

ADA Title III addresses public accommodations. The DOJ's Title III overview describes covered businesses and nonprofits, including shops, hotels and medical offices, as well as exclusions such as qualifying private clubs and religious organizations.

The DOJ's web accessibility guidance explains its position that the goods and services public accommodations offer online must be accessible. This is not a statement that every website has the same legal status or that courts decide every claim alike.

The Separate Title II Web Rule

Title II covers state and local governments. Its web and mobile app rule generally adopts WCAG 2.1 AA, with defined exceptions. The DOJ fact sheet explains scope and population calculations.

Under the extension effective April 20, 2026, the technical rule's compliance dates are April 26, 2027 for entities with a total population of at least 50,000, and April 26, 2028 for smaller entities and any special district government. Existing ADA duties continue before those dates. These Title II dates do not create a universal WCAG mandate or deadline for private businesses under Title III. Dates reviewed October 14, 2026.

WCAG as a Technical Framework

WCAG provides criteria for testing accessibility. A WCAG score does not settle every legal obligation. Use its four principles to organize technical work:

• Perceivable — Content must be presentable in ways that all users can detect, including those who are blind, deaf, or have low vision.
• Operable — Navigation and interactive elements must work for users who rely on keyboards, voice commands, or assistive technologies instead of a mouse.
• Understandable — Text must be readable, interfaces must behave predictably, and users must receive help avoiding and correcting errors.
• Robust — Content must be compatible with current and reasonably future assistive technologies, including screen readers.

Use these principles to guide testing and remediation. Legal obligations and the merits of a claim require their own assessment.

Start With the Services People Need

Prioritize barriers that stop people using your service, rather than an assumed ranking of which industries get sued. Review product selection and checkout, appointments, forms and important documents. Our e-commerce checklist and small-business guide describe practical checks. A sector label or automated score is not a legal risk assessment.

Common Website Barriers to Review

Review these barriers with automated checks and human testing. Their effect depends on the page and the task a person is trying to complete.

Missing or Inadequate Alternative Text

Images that convey information need appropriate text alternatives for people who cannot see them. Product photos, informational graphics and functional icons need alternatives suited to their purpose; decorative images need different treatment.

Inaccessible Forms and Checkout Processes

If a user who relies on a screen reader or keyboard navigation cannot complete a purchase, submit a contact form, or book an appointment on your website, that is a serious accessibility barrier. Common problems include form fields without associated labels, error messages that are not announced to assistive technology, and submit buttons that cannot be activated with a keyboard.

Poor Color Contrast

Text that does not have sufficient contrast against its background is difficult or impossible to read for users with low vision or color vision deficiencies. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Many modern website designs prioritize aesthetics over readability and fail this requirement.

Keyboard Navigation Failures

Not all users can operate a mouse. Users with motor disabilities, visual impairments, or certain neurological conditions depend on keyboard navigation. If your website has dropdown menus, modals, carousels, or interactive elements that cannot be reached and operated with the Tab and Enter keys alone, you have a keyboard accessibility gap.

Missing Page Structure and Headings

Screen readers rely on proper HTML heading hierarchy (H1, H2, H3) and landmark regions to help users navigate pages efficiently. Websites that use headings purely for visual styling — or that skip heading levels — create a confusing and disorienting experience for users of assistive technology.

Auto-Playing Media Without Controls

Video or audio content that plays automatically without accessible controls to pause, stop, or adjust volume creates barriers for users with auditory, cognitive, or seizure-related disabilities.

Third-Party Content and Widgets

Include third-party components in your testing. Chat widgets, payment processors and booking engines can block a journey even when the surrounding page works. Agree with vendors who will investigate and repair barriers; a scan does not determine legal responsibility.

Costs and Legal Outcomes Need Case-Specific Advice

There is no universal settlement price, defense budget or remediation deadline. A particular agreement or order may impose obligations beyond a scan's findings. Seek qualified legal advice for a demand or complaint. Technical testing can document barriers and repairs, but cannot predict a legal outcome.

A Practical Accessibility Roadmap

These steps help people use your website. They do not guarantee that a claim will be avoided or resolved.

Step 1: Conduct a Comprehensive Accessibility Audit

You cannot fix what you have not identified. Start with a thorough audit of your website against WCAG 2.1 Level AA criteria. Our WCAG compliance checklist provides a structured framework for this audit. This should combine automated scanning tools — which can efficiently detect many technical violations — with manual testing that evaluates the real user experience for people who rely on assistive technology.

Automated tools alone are not sufficient. Industry research consistently indicates that automated scanners can detect only a portion of WCAG violations. The remaining issues require human judgment to identify. For practical guidance on addressing the issues scanners find, see our guide on fixing accessibility issues found by automated scanners.

Step 2: Prioritize and Remediate Critical Issues

Focus first on barriers that prevent users from completing core tasks on your website:

• Can a screen reader user navigate your site and understand the content?
• Can a keyboard-only user complete a purchase, fill out a form, or access essential information?
• Is your content readable for users with low vision?

Fix these critical-path issues first, then work through the remaining violations systematically.

Step 3: Address Your Design and Development Process

One-time fixes are not enough. Accessibility must be integrated into your ongoing design and development workflow. Every new page, feature, or content update should be evaluated for accessibility before it goes live. Train your team on accessibility fundamentals. Include accessibility acceptance criteria in your development process.

Step 4: Publish an Accessibility Statement

An accessibility statement on your website demonstrates good faith and provides users with a way to report barriers they encounter. While an accessibility statement alone does not shield you from litigation, it signals that your organization takes accessibility seriously and is actively working toward compliance. Include contact information so users can request assistance or report issues.

Step 5: Implement Continuous Monitoring

Websites change as content, plugins and designs are updated. Repeat automated checks and human tests to find regressions. Monitoring can miss issues and does not prevent legal claims.

Step 6: Document Your Accessibility Work

Keep the scope, date, findings and limitations of each check, together with repair and retest records. This helps your team distinguish verified work from unfinished work. The legal significance of those records depends on the matter.

Accessibility Overlays: Do They Protect You?

Some businesses turn to accessibility overlay widgets — JavaScript tools that add a toolbar to your website claiming to fix accessibility issues automatically. It is important to understand that these overlays have significant limitations.

Do not treat a toolbar or a clean automated report as evidence that every journey is accessible. Test the experience with assistive technology and repair underlying barriers. The DOJ's web guidance recommends combining automated checks with manual checking.

Genuine accessibility requires fixing your website's code, content, and design — not layering a cosmetic tool on top of existing barriers. For a detailed analysis of why overlays fall short, see our guide on accessibility overlay widgets and whether they actually work.

Keep Scope and Dates Current

Use the primary DOJ sources above when reviewing requirements. Do not extend a public-sector rule to private businesses by analogy, or assume that a deadline extension removes existing accessibility duties. Additional laws or contractual terms may require a separate assessment.

Take the First Step Today

Start with an important public page, review its saved evidence and plan human testing of essential tasks. A11yScope provides automated findings and fix guidance for the state it checks; missing findings do not prove complete accessibility.

Run a free A11yScope scan, then combine the findings with keyboard, screen-reader and other human checks.