ADA Website Accessibility Compliance: A Founder's Guide to the 2024 DOJ Rule and Demand Letters

Most founders assume mobile-friendly means accessible. It doesn't — and courts are enforcing WCAG 2.1 AA against DTC brands and SaaS startups with increasing frequency.

ADA Website Accessibility Compliance for DTC Brands and SaaS Startups
Loading AudioNative Player...

Most founders we talk to share the same assumption: "our website works on mobile, so it's accessible." It is not. "Accessible" in the legal sense means that people with disabilities — blind users navigating with screen readers, keyboard-only users who cannot use a mouse, deaf users who need video captions — can perceive, operate, and understand your website. That is a different standard from mobile-friendly, and it is a standard that courts and regulators are enforcing with increasing intensity.

If you operate a DTC brand or SaaS startup, ADA website accessibility compliance is not a future concern. It is a current legal exposure. The Department of Justice issued its final ADA Title II web accessibility rule in April 2024, formally adopting WCAG 2.1 Level AA as the technical standard for state and local government websites. No equivalent Title III rule exists for private businesses yet — but private plaintiffs file thousands of demand letters and class action lawsuits every year under existing ADA Title III law, and the 2024 DOJ rule has effectively established WCAG 2.1 AA as the benchmark that courts expect across the board. Accessibility demand letters can cost $5,000 to $25,000 to resolve even when you win, because the cost of defense, remediation, and settlement is real regardless of the outcome.

The 2024 DOJ Rule: What It Says and What It Means for Private Businesses

On April 24, 2024, the Federal Register published the DOJ's final rule updating ADA Title II regulations to require that web content and mobile apps provided by state and local governments be accessible to people with disabilities. The rule specifically designates WCAG Version 2.1, Level AA as the technical standard for compliance. The DOJ's fact sheet explains that the rule sets "specific requirements about how to ensure that web content and mobile applications (apps) are accessible to people with disabilities" — including requirements for captions for videos, alt text for images, and keyboard navigation.

The rule applies to state and local governments (Title II), not to private businesses. The DOJ has not yet issued a parallel rule under Title III, which covers places of public accommodation — including, according to most courts that have ruled on the question, the websites of private businesses. But here is the critical point: the absence of a Title III rule has not stopped private litigation. Plaintiffs' attorneys file thousands of website accessibility lawsuits every year under existing Title III law, arguing that inaccessible websites discriminate against people with disabilities. And courts increasingly look to WCAG 2.1 AA as the standard for what "accessible" means — the same standard the DOJ just codified for Title II.

The compliance dates for the Title II rule were extended by one year via an interim final rule published in April 2026. State and local governments with populations of 50,000 or more must comply by April 26, 2027; smaller entities have until April 26, 2028. But for private businesses, the clock is already running — not because of the Title II rule, but because of the litigation environment that has been building for years and is now accelerating.

WCAG 2.1 AA: The De Facto Standard Courts Expect

The Web Content Accessibility Guidelines (WCAG) are developed by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative. WCAG 2.1, published in 2018, is the version the DOJ selected for its 2024 rule. Level AA is the middle conformance level — it includes the most critical accessibility requirements without imposing the most demanding ones reserved for Level AAA.

WCAG 2.1 AA is organized around four principles: websites must be perceivable (content can be perceived by users with disabilities, including through screen readers), operable (users can navigate and interact using keyboard, voice, or other assistive technologies), understandable (content and navigation are clear and predictable), and robust (content works with current and future assistive technologies). Within these principles, Level AA includes specific success criteria — such as requiring text alternatives for non-text content, captions for synchronized media, sufficient color contrast, no keyboard traps, and consistent navigation.

Even though no Title III rule mandates WCAG 2.1 AA for private businesses, courts have increasingly treated it as the standard of care. Settlement agreements in ADA web accessibility cases routinely require defendants to achieve WCAG 2.1 AA conformance within a defined remediation period. The DOJ's decision to adopt WCAG 2.1 AA for Title II effectively ratifies what private litigation had already established: if you are sued for website inaccessibility, the remediation target will almost certainly be WCAG 2.1 AA. This is why we advise founders to treat WCAG 2.1 AA as the operational standard — not because a regulation specifically requires it of your company today, but because every court and plaintiff's attorney already does.

How to Respond to an Accessibility Demand Letter

If your startup receives a demand letter alleging that your website is not accessible to people with disabilities, the first rule is: do not ignore it. These letters are typically sent by plaintiffs' attorneys who specialize in ADA web accessibility cases, and they are often the precursor to a federal lawsuit. Here is the sequence we recommend:

1. Engage counsel immediately. Do not respond to the letter yourself. A demand letter from a plaintiff's attorney is a legal communication that can be used against you. Have your attorney review the letter, assess the claims, and draft any response. This is not the moment to save on legal fees — the cost of a misstep in your initial response can multiply the eventual cost of resolution.

2. Conduct an accessibility audit. Commission a WCAG 2.1 AA audit of your website — both automated and manual testing, including testing with actual assistive technology users. The audit will tell you exactly what issues exist, how severe they are, and what remediation will require. This information is essential for both your legal strategy and your remediation roadmap.

3. Do not admit liability. A demand letter is an allegation, not a finding. Your response should acknowledge receipt, confirm that you take accessibility seriously, and commit to investigating the claims — without admitting that your website violates the ADA or any specific standard. Your attorney should craft this response carefully to avoid creating evidence that could be used against you.

4. Begin remediation immediately. Regardless of the legal posture, if the audit reveals genuine accessibility barriers, start fixing them. Courts and plaintiffs look favorably on companies that take prompt corrective action. If litigation follows, a documented remediation effort is your strongest evidence that you are acting in good faith. This is also where you should consider whether your existing digital compliance practices need updating across the board — accessibility is one part of a broader compliance picture.

5. Evaluate settlement vs. litigation. Most accessibility demand letters are resolved through settlement rather than litigation. Settlements typically include a monetary payment to the plaintiff (which covers their attorneys' fees), a commitment to remediate within a defined period, and ongoing monitoring. The cost of settlement — often $5,000 to $25,000 in attorneys' fees plus remediation costs — is frequently lower than the cost of defending a lawsuit to judgment. But this is a decision that should be made with counsel, based on the strength of the claims, your remediation timeline, and your risk tolerance.

6. Document everything. Keep records of your audit, your remediation steps, your communications with the plaintiff's attorney, and your compliance efforts going forward. If a second demand letter arrives from a different plaintiff — which happens frequently — your documented compliance program is your defense.

The Overlay Problem: Why Accessibility Widgets Are Not Compliance

Accessibility overlays — products like accessiBe, AudioEye, UserWay, and others that promise to make your website compliant through a single line of JavaScript — are not a compliance solution. This is not our opinion. It is the consensus of accessibility professionals, disability advocates, and now federal regulators.

The Overlay Fact Sheet, signed by hundreds of accessibility professionals and organizations, explains why: overlays apply third-party code to attempt to fix accessibility issues on the fly, but they cannot achieve full WCAG conformance. Automated repair of text alternatives for images is not reliable. Automated repair of keyboard access is not reliable. Automated repair of form labels, error handling, and focus control is not reliable. And overlays cannot fix content in PDFs, SVGs, or media files. The fact sheet is blunt: "full compliance cannot be achieved with an overlay."

In January 2025, the Federal Trade Commission made this point with enforcement action. The FTC issued an order requiring accessiBe to pay $1 million for deceptive claims that its AI product could make websites compliant with accessibility guidelines. The FTC found that accessiBe had misrepresented what its overlay could do, and the order prohibits the company from claiming that its products can make any website compliant with WCAG. As Lainey Feingold reported, the FTC's action confirmed what disability advocates had been saying for years: overlays do not deliver what they promise.

The litigation data reinforces this. According to the UsableNet 2024 Year-End Report on ADA digital accessibility lawsuits, more than 1,000 companies with accessibility widgets on their websites were sued for accessibility barriers in 2024. Installing an overlay does not protect you from being sued — and it may actually attract litigation, because plaintiffs' attorneys know that overlay-equipped sites often still have accessibility barriers.

For founders, the practical takeaway is this: an overlay may address a handful of accessibility issues, but it cannot bring your website into compliance with WCAG 2.1 AA. Real compliance requires fixing the underlying code and content of your website. There are no shortcuts.

The Privacy Intersection: When Overlays Inject Tracking Pixels

Accessibility overlays create a secondary risk that most founders never consider: privacy compliance exposure. The Overlay Fact Sheet identifies this risk directly: "Adding an overlay to your site may run counter to end users' preference for privacy and may create risk of noncompliance with GDPR, UK GDPR, CCPA, et al."

Here is why. Some overlays detect when assistive technology — such as a screen reader — is running on a user's device. This detection exposes the fact that the person using the device has a disability. In the case of screen reader users, the majority are blind or have low vision, meaning the overlay is collecting sensitive information about the nature of a person's disability. Disability is sensitive personal data under privacy laws like the GDPR, CCPA, and state privacy statutes. Collecting it without informed consent creates legal exposure.

Some overlays also persist user settings across sites that use the same overlay by setting a cookie on the user's computer. When a user enables a setting on one site, the overlay may automatically enable that feature on other sites — without the user ever opting in to being tracked. This cross-site tracking creates GDPR and CCPA risk for the company that installed the overlay, not just for the overlay vendor.

This privacy risk intersects with the broader compliance landscape that startups must navigate. As we have discussed in our coverage of the DOJ Data Security Program, third-party code that collects or transfers user data can create compliance obligations that extend far beyond what most founders anticipate. An accessibility overlay that injects tracking pixels or cookies may be collecting sensitive data you did not know you were gathering — and the legal responsibility for that collection rests with your company, not the overlay vendor.

If you currently use an overlay, audit what data it collects, how it collects it, and whether your privacy policy discloses that collection. If your privacy policy does not mention the overlay's data practices, you may have a disclosure gap that creates independent legal exposure — separate from any accessibility concerns.

The Practical Remediation Roadmap: Audit, Fix, Verify, Maintain

If you have not yet addressed website accessibility, here is the roadmap we recommend. It is not a one-time project — accessibility is an ongoing discipline, like security or privacy compliance. But the initial remediation follows a clear sequence.

Step 1: Audit

Commission a comprehensive WCAG 2.1 AA audit of your website and mobile app. The audit should include both automated testing (using tools like axe DevTools, WAVE, or Lighthouse) and manual testing by accessibility professionals, including testing with actual assistive technology users. Automated tools catch approximately 30-40% of WCAG issues; the rest require human evaluation. A thorough audit will produce a prioritized list of issues categorized by WCAG success criterion, severity, and remediation effort.

If you have received a demand letter, your audit should specifically address the issues identified in the letter — but do not limit the audit to those issues. Plaintiffs' attorneys often identify a subset of problems; a full audit will surface everything, preventing a second demand letter from a different plaintiff targeting issues the first letter did not mention.

Step 2: Fix

Remediate the issues identified in the audit. This is engineering work, not marketing work. Common fixes include: adding alt text to images, ensuring proper heading structure (H1, H2, H3 in logical order), providing keyboard navigation for all interactive elements, ensuring sufficient color contrast (at least 4.5:1 for normal text), adding captions and transcripts for video and audio content, labeling all form fields properly, providing error messages that are programmatically associated with the relevant form fields, and ensuring that focus indicators are visible and that focus order is logical.

For SaaS startups, pay particular attention to your application's interactive components — custom dropdowns, modals, data tables, and drag-and-drop interfaces are common sources of accessibility failures. These often require ARIA (Accessible Rich Internet Applications) attributes to communicate states and properties to assistive technology.

Step 3: Verify

After remediation, conduct a verification audit to confirm that the fixes are effective. This should include re-testing with the same automated and manual methods used in the initial audit, plus testing with assistive technology users. Verification is not optional — a fix that works in one browser may fail in another, and a fix that satisfies one WCAG criterion may inadvertently break another.

If you are resolving a demand letter or lawsuit, the settlement will likely require a verification report from an independent third party. Even if you are not in litigation, a verification report provides documentation that your compliance efforts are genuine — which is your best defense against future demand letters.

Step 4: Maintain

Accessibility is not a one-time fix. Every new page, new feature, new blog post, and new product update can introduce accessibility barriers. Build accessibility into your development workflow: train your engineering team on WCAG 2.1 AA, include accessibility checks in your QA process, and conduct periodic re-audits (at least annually, and whenever you launch a significant new feature). Consider adopting an accessibility statement page that describes your commitment to accessibility, your conformance level, and how users can report accessibility issues — this is both a best practice and evidence of good-faith compliance.

For DTC brands, accessibility compliance intersects with other consumer protection obligations. If you operate a subscription model, your accessibility remediation should happen alongside a review of your subscription billing and cancellation practices — both are areas where the FTC and private plaintiffs are actively enforcing, and both affect how consumers interact with your digital presence.

The Litigation Landscape: What to Expect in 2025 and Beyond

The volume of ADA web accessibility lawsuits has been climbing steadily. Florida, New York, California, and Texas are among the top states for accessibility litigation. The Seyfarth ADA Title III blog, which tracks federal court filings, reported that website accessibility lawsuits remain a significant portion of all ADA Title III filings — and demand letters that never reach federal court are far more numerous. According to reporting on the UsableNet year-end report, digital accessibility lawsuits surged in 2025, with both large companies and small businesses targeted.

The 2024 DOJ rule has accelerated this trend in two ways. First, it has raised awareness of WCAG 2.1 AA as the accessibility standard, giving plaintiffs' attorneys a clear benchmark to cite in demand letters. Second, it has signaled that the federal government treats web accessibility as a civil rights issue — which makes it harder for defendants to argue that the ADA does not apply to websites at all, an argument that most courts have already rejected.

For DTC brands, the risk is particularly acute. E-commerce websites are frequent targets because they are public-facing, transactional, and often complex — making accessibility barriers more numerous and more impactful. A blind user who cannot complete a checkout process has been denied access to a service that is available to other customers. That is the core of an ADA Title III claim.

For SaaS startups, the risk depends on whether your application is consumer-facing or enterprise-only. Courts have generally held that public-facing websites and consumer applications are places of public accommodation under the ADA. The analysis for B2B SaaS applications that require login and are not available to the general public is less settled — but if your marketing site, documentation, or support portal is public-facing, those pages are subject to the same accessibility expectations.

Received an accessibility demand letter — or want to build WCAG 2.1 AA compliance into your product before one arrives? We help DTC brands and SaaS startups assess ADA web accessibility risk, respond to demand letters, and build practical remediation roadmaps.

Get in touch

Actionable Next Steps

  1. Audit your website now — before you receive a demand letter. Commission a WCAG 2.1 AA audit of your public-facing website and mobile app. The audit will tell you where you stand and what remediation will cost. This is the single most important step you can take, because it converts an unknown risk into a known plan.
  2. Prioritize remediation by severity and impact. Not every WCAG failure carries the same risk. Focus first on barriers that prevent users from completing core tasks — checkout, account creation, contact forms, and navigation. Then address lower-impact issues like color contrast and heading structure.
  3. Do not install an overlay as a compliance strategy. The FTC's $1 million fine against accessiBe and the Overlay Fact Sheet's professional consensus are clear: overlays do not achieve compliance. If you already use one, treat it as a temporary partial measure while you remediate the underlying code — and audit its privacy practices immediately.
  4. Build accessibility into your development workflow. Train your engineering team on WCAG 2.1 AA. Add accessibility checks to your QA process. Conduct re-audits annually and after major feature releases. Accessibility that is bolted on after launch is always more expensive than accessibility built in during development.
  5. Publish an accessibility statement. Create a page on your website that describes your commitment to accessibility, your current conformance level, how users can report issues, and your remediation roadmap. This is evidence of good faith — and it is often what distinguishes a company that resolves a demand letter quickly from one that ends up in litigation.
  6. If you receive a demand letter, engage counsel immediately. Do not respond yourself. Do not ignore the letter. Do not delete the accessibility barriers the letter identifies without first preserving evidence. Have an attorney who understands ADA web accessibility litigation review the letter, commission an audit, and develop a response strategy. The cost of early legal intervention is a fraction of the cost of defending a federal lawsuit.
  7. Review your privacy policy for overlay-related disclosures. If you use or have used an accessibility overlay, ensure your privacy policy discloses the data collection practices of that overlay. If it does not, you may have an independent privacy compliance gap that could attract regulatory or class action attention.

ADA website accessibility compliance is not optional — it is a legal obligation that courts are enforcing and that the DOJ has formalized through regulation. The 2024 Title II rule may not apply directly to your private business, but it has established the standard that private litigation will enforce. DTC brands and SaaS startups that treat WCAG 2.1 AA as a product requirement, not a legal afterthought, will avoid the demand letters, settlements, and remediation costs that are driving thousands of lawsuits every year. The companies that wait will pay — in legal fees, in settlement costs, and in the reputational damage that comes from being sued for denying access to people with disabilities.