ADA Common Gaps Website Audit Tool
Scan your WordPress or web pages for common technical accessibility oversights frequently cited in ADA Title III digital litigation and demand letters.
Technical Deep-Dive: ADA Digital Accessibility Litigation
📌 On this page
- 1. How ADA Title III came to apply to websites
- 2. The anatomy of an accessibility demand letter
- 3. Why WordPress sites are disproportionately targeted
- 4. Serial plaintiff patterns and what they mean for risk
- 5. Beyond the technical fix: process and documentation
- 6. What this tool is (and is not) a substitute for
1. How ADA Title III came to apply to websites
The Americans with Disabilities Act was signed into law in 1990, years before the commercial web existed in its modern form, so the statute itself never explicitly mentions websites. Over the following decades, federal courts across different circuits have taken varying positions on whether a website qualifies as a "place of public accommodation" under Title III — some circuits have required a "nexus" to a physical location, others have extended coverage to purely online businesses. This ongoing judicial patchwork, combined with the Department of Justice's informal guidance treating WCAG 2.1 AA as a practical benchmark, is why website accessibility has become a significant and growing area of civil litigation despite the lack of a single explicit statutory requirement.
2. The anatomy of an accessibility demand letter
A typical demand letter identifies specific technical barriers found on the recipient's website (often via automated scanning tools similar in kind to the checks this tool performs), asserts these barriers violate ADA Title III and/or applicable state accessibility statutes, and proposes a settlement — remediation plus payment of the sender's attorney fees — as an alternative to formal litigation. Many of these letters are generated at scale by firms that scan large numbers of websites for the same handful of easily automatable issues, which is exactly why the six checks in this tool map so closely to what commonly appears in real letters.
3. Why WordPress sites are disproportionately targeted
WordPress powers a substantial share of the commercial web, and the ecosystem's strength — an enormous library of third-party themes and plugins — is also its accessibility weakness: most theme and plugin authors are not accessibility specialists, and default configurations frequently ship with unlabelled icon buttons (a hamburger menu, a search toggle, a cart icon), missing alt text on featured images, and form fields generated without proper label association. A site owner who never wrote a line of custom code can still inherit dozens of accessibility gaps purely from theme and plugin defaults, without ever realizing it.
4. Serial plaintiff patterns and what they mean for risk
A notable pattern in this area of litigation is a small number of plaintiffs (or law firms representing them) filing large volumes of similar claims against many different businesses, often using automated scanning to identify targets efficiently. Courts and commentators have raised concerns about this pattern in some jurisdictions, but it does not eliminate the underlying legal exposure — it means the practical risk calculus for many businesses is less about the probability of facing a uniquely tailored, expensive lawsuit and more about the higher-frequency, lower-severity risk of receiving a template demand letter targeting easily automatable, common issues exactly like the ones this tool checks for.
5. Beyond the technical fix: process and documentation
Organizations serious about reducing accessibility legal risk typically do more than fix flagged issues one-off: they establish an accessibility policy, publish an accessibility statement with a real feedback channel (see the Accessibility Statement Generator below), conduct periodic professional audits rather than one-time fixes, and train content editors to maintain accessibility standards going forward (adding alt text to new images, using proper heading structure) so that fixes do not silently regress as new content is published. A remediated snapshot that decays within months as new content is added provides limited ongoing protection.
6. What this tool is (and is not) a substitute for
This tool is a fast, free way to surface a handful of the most commonly cited technical gaps so you can prioritize obvious, high-value fixes — it is genuinely useful for that narrow purpose. It is not a substitute for a comprehensive WCAG 2.1/2.2 AA audit (which covers dozens of additional criteria this tool does not check), not a substitute for manual testing with real assistive technology, and not legal advice or a certification of any kind. If accessibility compliance is materially important to your organization — due to size, industry, or existing legal exposure — engage a qualified accessibility auditor and legal counsel rather than relying on any single automated tool, including this one.
Frequently Asked Questions
What is Title III of the Americans with Disabilities Act (ADA)?
ADA Title III prohibits discrimination on the basis of disability in places of public accommodation. US Department of Justice guidance and federal court rulings broadly interpret public accommodation to include commercial public websites, requiring websites to be accessible (commonly benchmarked against WCAG 2.1 Level AA).
Does passing this diagnostic mean my website is legally compliant with the ADA?
No. This tool provides a technical scan of common automated oversights. It is NOT legal advice, does NOT certify legal compliance, and does NOT protect against demand letters. Comprehensive legal and technical compliance requires thorough manual auditing and review by legal counsel.
Why are WordPress sites frequently targeted by accessibility demand letters?
WordPress powers over 40% of the web. Third-party themes, page builders, and plugins often introduce unlabelled icon buttons, low-contrast text, missing form labels, and skipped headings without site owners realizing it.
Does this tool enforce SSRF security checks?
Yes. All live audits enforce strict SSRF safeguards, blocking requests to private networks, loopbacks, and cloud metadata IPs.
What exactly does the 6-point scan check, and what does it not check?
It checks for missing image alt attributes, unlabelled icon-only buttons, form inputs without associated labels, empty hyperlink tags, a missing HTML lang attribute, and a missing/empty page title — six of the most frequently cited technical issues in real accessibility demand letters. It does not check color contrast, keyboard operability, focus indicators, video captions, or the semantic correctness of heading structure, none of which can be reliably assessed from raw HTML alone. A truly comprehensive pre-litigation risk audit needs to cover a much broader set of criteria than these six.
Why do accessibility demand letters specifically target these particular issues?
Missing alt text, unlabelled buttons, and unlabelled form fields are disproportionately common in real-world sites (especially those built with page builders and third-party plugins that do not enforce accessible markup by default), are trivially easy for an automated scanning tool used by a plaintiff's firm to detect at scale across thousands of sites, and are unambiguous, hard-to-dispute violations once identified — a missing alt attribute is a binary, objective fact, unlike more subjective criteria. This combination of prevalence, detectability, and clarity is exactly why these particular gaps appear so often in real litigation.