An ADA demand letter should trigger evidence, not panic. Start by checking the website, preserving the facts, and involving counsel when needed.
A demand letter is not the time to guess
If a business receives an ADA website demand letter, the first reaction is usually stress.
That is understandable. It is also the moment when guessing gets expensive.
Before anyone argues, ignores the letter, buys a plugin, or starts a rushed redesign, the useful first step is to preserve the facts and check the public website. What pages were named? What barriers were alleged? What does the site actually show today?
An accessibility scan does not replace legal advice. It does give the owner, developer, and attorney a clearer starting point.
Separate legal response from technical evidence
The legal response belongs with qualified counsel.
The technical evidence belongs in a clear audit trail: scanned URL, date checked, detected issues, screenshots, severity, WCAG mapping, and the first fixes that would reduce user barriers.
Those are different jobs.
Mixing them creates confusion. A developer should not guess at settlement strategy. An attorney should not have to reverse-engineer whether the site has missing labels, contrast failures, inaccessible navigation, or broken forms.
The strongest response starts by keeping those lanes clear.
Check the public user path first
Demand letters often focus on whether a visitor can use the site, not whether the codebase looks elegant.
That means the first technical review should look at the public user path:
navigation
forms
calls to action
booking, checkout, or intake flows
documents and menus
mobile behavior
pages that create trust or revenue
If the issue appears in a repeated template, one fix may improve many pages at once. If the issue is tied to a vendor widget or embedded tool, the owner still needs to understand how that widget affects the public experience.
A scan is a starting artifact, not a compliance certificate
No automated scan can certify ADA compliance.
That matters because false certainty is dangerous in both directions. A clean scan does not prove every user journey works. A failing scan does not prove every flagged item is a legal violation.
The value of a scan is that it creates a fast evidence baseline. The value of a paid report is that it turns that baseline into a developer-ready remediation artifact with screenshots, severity, WCAG mapping, and code-context guidance.
For many small businesses, that is the right first technical step before deeper manual review.
What to preserve before changing the site
If there is a real legal threat, preserve the current facts before making sweeping changes.
Save the letter. Record the date. Note the pages or barriers mentioned. Capture the current public pages. Run the scan. Keep the report. Then coordinate changes with counsel and the developer.
That does not mean delaying obvious fixes forever. It means making sure the remediation path is documented instead of chaotic.
The practical first response
Start with the ADA audit overview.
Run the free scan on the relevant public URL.
If the scan shows meaningful issues, use the report to organize the first fixes and share the evidence with the right people.
If the matter is already legal, use the accessibility legal intake guide and talk to qualified counsel.
The goal is not panic. The goal is a better first response: evidence, priorities, and a documented path toward removing real barriers.
Want answers specific to your site?
A free scan takes 60 seconds. The sample report shows exactly what a paid audit artifact looks like before you buy.