You Got an ADA Website Demand Letter. Now What?

The letter usually arrives by email to a general inbox, gets forwarded twice, and lands on the desk of whoever is closest to the website. It cites the Americans with Disabilities Act, names specific barriers, and often proposes a settlement figure. The instinct in the first hour is either to panic or to dismiss it. Both are wrong.

This article is general information, not legal advice. Involve your own counsel.

The short answer

Route the letter to legal counsel before anyone replies, preserve the current state of your site rather than altering it, run a full baseline scan to establish what is actually true, and start a documented remediation program. The thing that protects an organization in this situation is not a claim of perfection. It is a dated record showing an active, good-faith effort, which is exactly what an organization that has never tested its site cannot produce.

What a demand letter is, and is not

A demand letter is a formal legal communication, typically from a firm representing an individual who asserts they encountered barriers on your site. It generally describes the alleged barriers, references the ADA and often specific WCAG success criteria, and asks for some combination of remediation commitments, attorney fees, and a settlement payment.

It is not a lawsuit, a court order, or a finding of fact. Receiving one does not mean you have been found to violate anything.

It is also not something to ignore. A meaningful share of web accessibility matters begin this way rather than with a filed complaint, and non-response is frequently what escalates them.

Two things have made these letters more common. First, there is now a clear federal technical standard for public entities: the DOJ’s Title II rule names WCAG 2.1 Level AA, with compliance dates of April 26, 2027 and April 26, 2028 depending on population, as set out in the DOJ fact sheet on the web and mobile app rule. A claimant no longer has to argue about what accessible means. Second, the underlying barriers are genuinely widespread: WebAIM’s February 2026 study of the top one million home pages detected WCAG failures on 95.9 percent of them, averaging 56.1 errors per page.

The first 48 hours

1. Send it to counsel before anyone answers

This is the step organizations most often get wrong, usually with good intentions. A web manager replies helpfully, explains what the team already knows is broken, and creates a written record of an admission. Route the letter to your general counsel, your risk office, or outside counsel, and instruct the team that nobody responds directly.

2. Preserve the site as it is

Do not take pages down. Do not quietly patch the specific items named in the letter and say nothing. Do not delete anything.

Altering or removing content after receiving a legal communication raises preservation questions that are far more damaging than the original accessibility issues. Capture the current state instead: a full scan with a timestamp gives you a defensible snapshot of what the site looked like on the day the letter arrived.

3. Notify the people who need to know

Typically leadership, communications, IT, and whoever owns the web platform. Keep the circle appropriate and let counsel guide what is put in writing. This is not the moment for a wide internal email speculating about liability.

4. Establish what is actually true

The letter describes specific barriers, usually a handful, often on the homepage or one transactional page. Those may be accurate, partly accurate, or already fixed. What matters more is the overall picture, because a claim rarely stays limited to the pages originally cited.

Run a full-site scan, not a check of the named pages. You need to know your real posture across every property before counsel advises on a response, and you need it dated.

What not to do

Do not install an overlay as a response. The impulse is understandable: a script promising instant compliance, deployable this afternoon. But an overlay changes what a visitor browser renders, not the HTML your server sends, and the served HTML is what an expert testing your site examines. Overlays have drawn both litigation and regulatory scrutiny in the United States. Adding one after a claim does not create a remediation record and may invite questions about what you believed you were fixing.

Do not commission a single point-in-time audit and stop there. An audit that identifies several thousand violations and is then filed away creates documentation that you knew about problems you did not address. If you are going to look, plan to act on what you find.

Do not promise a completion date you have not scoped. Timelines offered in a response become commitments. Scope from a real baseline first.

Do not treat it as purely a legal problem. Settling one letter without remediating leaves the same barriers in place for the next claimant, and for the users who actually encounter them.

What actually helps

The standard that matters in practice is not perfection. No large site is fully conformant at any given moment, and automated testing alone cannot even measure full conformance: coverage runs to roughly a third to 40 percent of success criteria, and the W3C states plainly in its evaluation guidance that “no tool alone can determine if a site meets accessibility standards. Knowledgeable human evaluation is required.”

What distinguishes an organization that took the obligation seriously is a documented, continuous program. Concretely, that means being able to answer four questions with dated artifacts:

An organization that can produce those four things is in a substantially different position from one that can produce none of them, regardless of the raw violation count on day one.

The program that follows

Once counsel has the letter and you have a baseline, the work is the same program any organization should be running:

1. Prioritize by severity and reach. Critical barriers on transactional pages first, then high-reach template issues.
2. Fix templates before pages. Most sites carry the bulk of violations in five to ten reusable templates, so early work clears disproportionate ground.
3. Cover the documents. PDFs are in scope and are frequently the largest untracked liability on institutional sites.
4. Verify every fix with a re-scan. An unverified fix is a claim.
5. Monitor continuously. New content reintroduces violations, and a claim resolved today does not prevent the next one.

Our ADA website remediation guide covers that sequence in depth, and how to make a website ADA compliant covers the standard itself and how to staff the work.

Where GuardGrid fits

GuardGrid is built to produce exactly the record described above. It crawls every page on a property, grades each one against WCAG 2.1 and 2.2 weighted by severity, names the exact failing element and the criterion it breaks, shows the violation marked in place on a page screenshot, and tracks each finding from open to fixed with re-scan verification. The Compliance Evidence PDFs, VPAT 2.5, and publishable accessibility statement are generated from your real scan data and timestamped, so the trend is documented rather than asserted.

The platform finds, documents, and tracks. It does not rewrite your code or write changes back to your CMS. When your team does not have capacity to work the list, our ADA remediation service puts Revion Solutions engineers in your codebase to make the fixes and document them, which in a post-letter situation is usually the bottleneck that matters.

If you are also evaluating what class of tool to use going forward, our comparison of ADA compliance tools sets out the categories honestly, including where we are not the right answer.

The most useful thing you can do in the next hour is get the letter to counsel. The most useful thing you can do this week is run a full scan so that whatever comes next, you are working from facts.