ADA Website Compliance: What US Businesses Actually Need to Build

“

Meerako — A Dallas-based technology partner helping US businesses build genuinely accessible, lower-risk websites.

Website accessibility lawsuits under the Americans with Disabilities Act have grown substantially in the US over recent years, with federal court filings alleging inaccessible websites numbering in the thousands annually, and California, New York, and Florida consistently accounting for a disproportionate share of filings — though businesses in every state face real exposure, since federal ADA claims aren't limited by where the defendant business is located. The legal landscape remains genuinely, frustratingly ambiguous: the ADA itself predates the modern web by several years, it doesn't explicitly address websites anywhere in its statutory text, courts have reached inconsistent conclusions on exactly what's required and even on more basic questions like whether a website with no connected physical location qualifies as a "place of public accommodation" at all, and the Department of Justice has issued guidance pointing toward accessibility standards without ever finalizing specific, binding website accessibility regulations under Title III.

For business owners, this ambiguity is itself the risk. There's no single definitive legal checklist a business can complete and point to as proof of compliance — only a genuinely prudent standard worth building toward, and a real, demonstrated track record of good-faith effort that meaningfully affects how a complaint or lawsuit plays out in practice, even without guaranteed legal immunity. This isn't a hypothetical concern reserved for large enterprises, either — a substantial share of the businesses named in ADA website lawsuits each year are small and mid-size companies, often targeted specifically because automated scanning tools that plaintiffs' firms use to identify potential targets don't discriminate based on company size, and a small business's website is just as easy to scan for an obvious accessibility failure as a Fortune 500 company's.

This post walks through why the legal landscape is structured the way it is, what practical standard has emerged in its absence, who actually gets targeted and why, and — most importantly — what businesses should actually build, beyond a narrow developer checklist mentality that misses the larger point of what genuine accessibility work requires.

• Why the ADA website compliance legal landscape is genuinely ambiguous
• What WCAG 2.1 AA has become as the practical, widely-cited standard
• The real risk profile — who actually gets sued, and why
• What businesses should actually build, beyond a narrow developer checklist
• What a realistic accessibility remediation project looks like in practice
• Common mistakes businesses make when addressing accessibility

The ADA's Title III requires "public accommodations" to be accessible, but doesn't specifically define website accessibility requirements — unsurprising, since the statute was written in 1990, several years before the commercial web existed in any meaningful form. Federal courts have disagreed on foundational issues, including whether a website with no connection to a physical location even qualifies as a "public accommodation" under the law, an unresolved circuit split that means the answer can genuinely differ depending on where a business is sued. This genuine legal ambiguity means there's no simple, universally agreed-upon compliance checklist — which paradoxically makes proactive, good-faith accessibility work more important, not less, since a business can't point to a clear regulatory bar it definitively met and rest easy; the best available defense is a demonstrated, ongoing, good-faith effort toward a widely-recognized standard.

In the absence of specific ADA website regulations, the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA has become the practical, widely-cited standard — courts frequently reference it in settlements and rulings, and the DOJ's own guidance points toward it, even without formally adopting it as binding regulation under Title III. WCAG 2.1 AA covers a substantial, well-defined set of specific technical criteria: sufficient color contrast, keyboard navigability for all interactive elements, meaningful alt text on informational images, properly labeled form fields, captions on video content, and a logical, navigable structure for screen reader users, among many other specific success criteria. Building toward WCAG 2.1 AA is the most defensible, practical approach available given the absence of clearer statutory guidance, and it's worth noting that WCAG 2.2 has since been published with additional success criteria — businesses building new accessibility programs in 2026 are well served by targeting 2.2 AA where practical, since it's a strict superset of 2.1's requirements plus additional criteria addressing gaps identified since 2.1's publication.

ADA website lawsuits disproportionately target businesses with an obvious, easily-testable accessibility failure — no alt text on meaningful images, forms that can't be completed via keyboard navigation, video content with no captions, or a checkout process a screen reader user genuinely cannot complete — often identified by automated scanning tools that plaintiffs' firms use to find easy, demonstrable targets at scale before a single lawsuit is ever filed. This means even businesses that feel accessibility isn't a priority given their size or industry face real, non-trivial risk if basic, easily-detectable issues exist on their site, and it's worth understanding that automated scanning genuinely does catch a meaningful share of common failures — meaning a business that's never run even a basic automated accessibility scan on its own site is, in a real sense, flying blind about its own exposure.

Beyond a narrow "developer checklist" mentality, genuine accessibility requires several things working together. Real automated and manual testing: automated scanners catch a meaningful share of issues (contrast ratios, missing alt attributes, unlabeled form fields) but miss others that require actual screen reader and keyboard-navigation testing by a person actually using those tools, since some accessibility failures — a logically confusing tab order, or content that technically has alt text but describes the image poorly — simply can't be caught by automated tooling alone. A documented accessibility policy and remediation process: demonstrating genuine good-faith effort matters both ethically and, practically, in how a business's response to a complaint or lawsuit is perceived by a court or by opposing counsel deciding whether litigation is worth pursuing. And ongoing monitoring as new content and features are added, since accessibility isn't a one-time project — new pages and features can introduce new issues if accessibility isn't built into ongoing development practice, and a business that passed an audit eighteen months ago but has shipped a dozen new features since without accessibility review is likely no longer in the state that audit certified.

A genuine accessibility remediation effort for an existing website typically starts with a combined automated and manual audit establishing a real baseline — not just a scanner report, but actual findings from someone testing with a screen reader and keyboard-only navigation across the site's key user flows, particularly anything involving a form, a checkout process, or interactive content. From there, findings get prioritized realistically: issues blocking a core user flow (an unusable checkout for keyboard users, for instance) take priority over lower-impact issues (a decorative image missing alt text that a screen reader would simply skip anyway if properly marked as decorative). Remediation work then proceeds against that prioritized list, followed by verification testing to confirm fixes actually resolved the underlying issue rather than just suppressing the automated scanner's flag. The realistic timeline for a meaningful remediation project on an established site with real functional complexity typically runs from several weeks for a narrowly scoped site to a few months for a larger, more complex site with many templates and interactive flows — and critically, this needs to be followed by an ongoing practice, not treated as complete once the initial remediation list is cleared.

Accessibility work isn't purely defensive risk management — a substantial share of the US population, commonly cited around one in four adults, lives with some form of disability, meaning an inaccessible website is directly excluding real customers, not just carrying legal risk. Building genuinely accessible experiences is both the right thing to do and, quite directly, a real market opportunity most businesses underinvest in, particularly as the population continues aging and age-related vision, hearing, and motor accessibility needs become more common among a business's existing and prospective customer base, not just a distinct minority segment.

The most common mistake is treating an automated scanner report as a complete accessibility audit, fixing everything it flags, and considering the job done — automated tools genuinely miss meaningful categories of issues that only manual testing catches, and a business that stops at automated remediation has real, undiscovered exposure it doesn't know about. A second common mistake is treating accessibility as a one-time project rather than an ongoing practice, letting a certified-compliant site drift out of compliance as new features ship without accessibility review built into the development process. A third, particularly costly mistake is responding to a demand letter or lawsuit threat defensively and adversarially rather than engaging a genuine, documented remediation effort quickly — businesses that can demonstrate real, prompt, good-faith remediation activity are generally in a meaningfully better position, both practically and in settlement negotiations, than those that ignore the issue or respond purely through counsel without any actual technical remediation underway.

We build toward WCAG 2.1 AA (and 2.2 AA where practical) as the practical standard, combining automated testing with genuine manual verification — screen reader testing, keyboard navigation testing across real user flows — and help clients establish an ongoing accessibility practice, not a one-time audit, since new content and features need the same accessibility discipline applied continuously, not just at initial launch or in response to a legal threat.

ADA website compliance sits in genuinely ambiguous legal territory, which makes proactive, good-faith accessibility work — built toward WCAG 2.1 AA, backed by genuine automated and manual testing, and sustained as an ongoing practice rather than a one-time checklist — the most defensible approach available, while also representing real business opportunity most companies leave on the table by excluding a meaningful share of potential customers.

Concerned about your website's accessibility and legal risk? Let's run a genuine assessment and build a real remediation plan.