You received an ADA demand letter about your website.
Send it to your attorney first — we are not a law firm. Then, separately, there is engineering work to do: the barriers the letter alleges have to be found, fixed in your code, and documented with dates. Here is what that looks like, and what to do in the next 48 hours.
No sign-up to read this · Not legal advice · Written by engineers, not marketers
Five things to do now.
No sign-up, no email required. This is what we would tell you on a call.
- 01
Send it to an attorney
Before anything else, and before you reply to anyone. We are not a law firm and cannot tell you what the letter means for you. If you do not have counsel, your business insurer or local bar referral service is the fastest route to one.
- 02
Do not contact the sender yourself
Anything you say can become part of the record. Let your attorney handle the correspondence and decide what, if anything, is said.
- 03
Preserve the current state of the site
Before you change anything, take a dated capture of the pages named in the letter. What the site looked like when the letter arrived can matter later, and recovering it from backups afterwards is not always possible. Coordinate the timing of any fixes with your attorney.
- 04
Do not rush to install an overlay widget
The instinct is to buy the thing advertising one-line compliance. A widget installed this week does not change the code the letter is about: it runs in the visitor's browser after your page has already been delivered, so the underlying markup a complaint cites is still the markup you shipped. Fix the code, and keep the record of having fixed it.
- 05
Start a dated record of remediation
What a good-faith effort looks like later is a timestamped trail: what was found, what was changed, when, and what a re-scan showed afterwards. That record is worth starting the day the letter arrives, whoever does the work.
A dated record, not a badge.
Whoever does the work — your developer, an agency, or you — the artefact that matters afterwards is the same four things.
- A dated baseline. A scan run today, with a timestamp, a score and a list of every issue found — before anyone touches the code. This is the document that makes everything after it legible.
- Findings tied to the standard. Each issue mapped to the WCAG success criterion it fails and the level it sits at, not a vague severity word. That is what a developer works from and what an auditor recognises.
- Proof the fixes landed. Re-scan the same pages after the work and keep both reports. Two dated documents showing the same site before and after is the whole point.
- Something that keeps running. Sites regress. Scheduled scans catch the day a theme update reintroduces a barrier, which is a far better story than discovering it in a second letter.
Questions people ask at this point.
Start with a dated baseline.
It takes about a minute.
Create a free account, paste the URL from the letter, and get a timestamped WCAG 2.2 AA score with your top issues on screen. No card. Whatever you decide to do next, you will be doing it with the facts.