Is ADA Compliance Mandatory for Websites?

Short answer: There is no single sentence in the ADA that says “websites must be ADA compliant.” Still, many US courts, federal guidance and enforcement actions treat websites as covered when they connect to a business that serves the public. That makes accessibility effectively required for most businesses that operate in or sell to the US. This article explains how, when and why you should make your site accessible.

How the ADA can apply to a website

Title III of the ADA bans discrimination by places of public accommodation. Courts have differed on whether a website alone counts as a “place.” Some rulings find the ADA applies when a website has a strong link to a physical place of business. Other rulings have been less clear.

The US Department of Justice has consistently said web access is important, but it has not issued a single, final regulation that explicitly spells out website rules. At the same time, federal procurement rules require government sites and contractors to meet accessibility standards aligned with WCAG. The practical result is this: private businesses face real legal risk if their public-facing digital services are inaccessible.

What “mandatory” means in practice

Mandatory can mean different things depending on context.

• For federal agencies and contractors: accessibility requirements are explicit under Section 508 and related procurement rules.
• For private businesses: no single statute says “make your website accessible or else,” but lawsuits, demand letters and settlements commonly require remediation. Courts, settlement agreements and corporate procurement rules frequently point to the W3C’s WCAG as the technical standard to meet.
• For state laws and contracts: some states use state disability or consumer protection laws to require accessible services. Contract terms and procurement policies also create binding obligations.

Which standard should you use?

WCAG (Web Content Accessibility Guidelines) is the accepted technical standard across government and private settlements. Aim for Level AA as a practical baseline. Use semantic HTML, ARIA only where needed, and test with assistive technologies such as screen readers and keyboard navigation.

Which websites are most at risk?

• Sites tied to a physical place of public accommodation: retail stores, restaurants, hotels and medical centres.
• Ecommerce sites that sell to US customers or handle payments and customer accounts.
• Sites for colleges, schools, and any organisation that receives federal funds.
• Sites used for essential customer interactions: bookings, ticketing, account management and checkouts.

Step-by-step remediation plan you can use today

1. Quick risk triage (1 week)

• Decide scope: public pages, account flows, apps, PDFs and media.
• Run an automated scan on a representative set of pages across templates.
• Do a manual keyboard pass and a basic screen reader walk-through on high-risk pages.

2. Full audit (2 to 6 weeks depending on site size)

• Automated testing across the site plus manual review of templates and interactive flows.
• Include manual checks for focus order, skip links, semantic headings, form labels, and colour contrast.
• Document issues with severity: P1 (blocks access), P2 (major usability), P3 (cosmetic).

3. Remediation sprints (ongoing)

• Fix P1 issues first. Use source control and small deployable changes to avoid regressions.
• Retest fixes with automated tools and fresh manual checks. Include assistive-tech users for validation.
• Maintain an accessibility backlog and estimate fixes in story points or hours.

4. Acceptance and monitoring

• Set acceptance criteria tied to WCAG AA success criteria for the pages in scope.
• Schedule periodic automated scans and monthly manual checks on critical user journeys.
• Keep an accessibility statement and remediation roadmap public if you operate in the US or EU.

Common mistakes that lead to liability

• Relying only on automated tools. They catch roughly 20 to 50 percent of issues.
• Fixing single pages without addressing templates or CMS patterns that reintroduce problems.
• Using ARIA as a substitute for semantic HTML.
• Ignoring non-HTML assets: PDFs, videos without captions, and images without proper descriptions.
• No ongoing governance: accessibility must be in design, development and content workflows.

If you receive a demand letter or are sued

Do not ignore it. Preserve records about your accessibility efforts. Immediately start the triage and audit steps above. Speak to an attorney who specialises in accessibility law for your jurisdiction. Many organisations reduce risk by negotiating a remediation timeline and a declaration of compliance rather than fighting the claim in court.

International note for UK and EU readers

The ADA is US federal law and applies only in the United States. In the UK, the Equality Act 2010 addresses discrimination and accessibility expectations. The EU has accessibility rules such as the European Accessibility Act and web accessibility requirements for public sector bodies. If you operate internationally, comply with US, UK and EU rules that apply to your users and contracts.

Quick decision checklist

• Do you serve US customers or have a US physical location? If yes, prioritise accessibility.
• Do you handle payments, accounts or bookings? High priority.
• Do you have federal contracts or a public sector audience? Compliance is mandatory for those contracts.
• Can you publish an accessibility statement and remediation plan? If not, start one now.

Bottom line

The ADA does not contain a single clause that reads “websites must be accessible,” but the legal and commercial ecosystem effectively makes accessibility mandatory for most organisations that serve the public in the US. Use WCAG AA as your technical target. Test manually with assistive tech, fix prioritized issues quickly and keep accessibility in your design and development workflow.