ADA Demand Letter for Your Website? Start Here

A letter arrives. It names your website, cites the Americans with Disabilities Act, lists barriers a user encountered, and proposes a figure to make it go away.

The first hour after that lands is usually spent panicking, and the panic produces bad decisions. This is a technical triage checklist for that hour — what to do, what to check, and what not to do.

Read this part first. I am not an attorney and nothing here is legal advice. Before you reply to the sender, before you negotiate, before you agree to anything, talk to a lawyer. What follows is the technical work that runs alongside your legal response, not instead of it.

Do not do these three things

Do not contact the sender yourself

Not to explain, not to push back, not to ask for time. Anything you write can be used to establish what you knew and when. Route it through counsel.

Do not quietly change the site and say nothing

Fixing the issues is right. Doing it silently while hoping nobody notices is not a strategy, and rushed changes made in a panic tend to break things — sometimes including the very flows the letter complains about.

Do not install an overlay

This is the single most common reaction and it is the wrong one. Overlay widgets promise compliance from one line of JavaScript. They have appeared in US ADA litigation rather than preventing it, and many people who use assistive technology report overlays interfere with the tools they already rely on. An overlay does not fix your markup. It sits on top of it. Installing one after receiving a letter also tells a story you may not want to tell.

Preserve what the site looked like

Before anyone touches anything, capture the current state. If your site changes over the following weeks — and it should — you want a record of what it was when the letter arrived.

• A full backup of the site as it stands today, kept somewhere it will not be rotated out
• Screenshots of the specific pages the letter names
• Your deployment history, so you can show what changed and when
• Any prior accessibility work — previous audits, tickets, remediation records

That last one matters more than people expect. Evidence that you were already working on accessibility before the letter arrived is a materially better position than a blank history.

Read the letter as a technical document

Most demand letters list specific barriers. Some are precise and cite success criteria. Others are vague — “the site is not navigable by screen reader” — and a few are clearly generated from an automated scan run against a template.

Work through what it actually claims and sort each item into three buckets:

• Reproducible. You can trigger it yourself. These are real and they are your priority.
• Plausible but unverified. The claim is credible but the letter is too vague to test. Investigate.
• Not reproducible. You have tried and cannot make it happen. Document your testing method — browser, assistive technology, version, steps. Do not simply assert it is wrong.

Give this to your lawyer as a factual annex. A structured technical response is far more useful to counsel than “we think most of this is nonsense.”

Test the purchase path yourself, today

You do not need a specialist for the first pass. You need thirty minutes and your own website.

Unplug your mouse

Seriously. Then try to buy something. Tab through the site from the top of the homepage: search, a product, add to cart, checkout, payment. Note every point where you get stuck, where you cannot tell what is selected, or where Tab takes you somewhere unexpected.

Most people doing this on their own site for the first time do not reach payment. If you cannot complete a purchase with a keyboard, neither can a portion of your customers, and that is usually the substance of the complaint.

Turn on a screen reader

VoiceOver is built into macOS — Command + F5. NVDA is free on Windows. You will be bad at using it, which is fine; you are not testing your own skill. Listen to a product page. Do the images say anything useful? Does the price get announced? When you submit a form with an error, does it tell you what went wrong?

Check the obvious visual failures

• Is body text at least 4.5:1 against its background (SC 1.4.3)?
• Can you see where keyboard focus is at all times (SC 2.4.7)?
• Do all product images have meaningful alternative text (SC 1.1.1)?
• Are form errors described in text, not just a red outline (SC 3.3.1)?

These four account for a large share of what appears in demand letters, and you can assess them in an afternoon.

What self-checking usually misses

Three of these came to us after the business had looked at the site themselves and found nothing obvious.

One retailer contacted us after a demand letter arrived. The first thing we checked was the navigation. Visually it was fine, but the dropdown menu could not be opened properly with the keyboard, which meant a keyboard-only user could not reach entire product categories. Not buried deep in the code — the main path customers use to shop.

A Shopify store had a clean-looking product page where the size and colour options were not properly announced to screen reader users. A sighted customer could see which option was selected; a blind customer got no confirmation. The owner had looked at that page many times and never noticed, because the problem was not visual.

Another business had strong brand colours throughout, but several call-to-action buttons failed basic contrast. They looked stylish. For users with low vision they were hard to read, particularly on mobile — and they were exactly the places customers were expected to click, continue and buy.

In a fourth case, testing with the keyboard alone showed the focus indicator disappearing on several links and buttons, so there was no way to tell where you were on the page. A small visual detail that makes a site extremely difficult to use without a mouse.

Fix in the order that matters

Not alphabetically, not easiest-first. In the order that reflects real user harm and real exposure.

1. Anything blocking a purchase

Checkout, cart, payment, account creation. A customer who cannot complete these is being excluded from your business outright.

2. Everything the letter specifically named

Whether or not you think each claim is strong. Fixing named items is demonstrable good faith.

3. Site-wide component failures

Your site is templated. One broken form field, one unlabelled button, one missing focus style — each is broken on every page using that component. Fix at source and the problem disappears everywhere at once.

4. Everything else, on a written schedule

You are not expected to fix everything in a fortnight. You are expected to have a plan with dates and to be visibly working through it.

Keep a record as you go

From the moment you start, write down what you change.

• What was fixed, on what date, by whom
• Which success criterion each fix addresses
• How it was verified, and with what assistive technology
• What remains, and the date it is scheduled for

Update your accessibility statement to describe your actual position honestly — including what is not yet conformant. An honest statement with a dated remediation plan is a stronger position than a claim of full conformance you cannot support. Overclaiming in an accessibility statement can itself become a problem.

Is this a real complaint or a template?

Both exist. Some letters come from individuals with a genuine grievance. Others are volume operations, generated from automated scans, sent to hundreds of businesses.

Here is the uncomfortable part: it does not change what you should do. If the barriers are real, they are real regardless of the sender’s motive, and they are excluding customers whether or not anyone writes to you about it. The technical work is identical.

Whether the letter itself is worth contesting is a legal question, and it is your lawyer’s to answer, not mine.

Afterwards

Most businesses that go through this arrive at the same conclusion: the fixes were not as expensive as feared, and the site works better than it did.

The thing to avoid is letting it happen twice. That means accessibility built into how you work — components checked before they ship, editors who know what alternative text is for, a periodic audit rather than a crisis. Teams that do this stop generating new violations. Teams that remediate once and move on are back in the same position within two years.

If you need help now

If you have received a letter, say so in your first message and it moves to the front of my queue. You will get findings mapped to specific success criteria, prioritised by what actually blocks a purchase, with the changes required — in a form your developers can act on and your lawyer can use. Remediation runs through EcomBack, a court-approved accessibility provider.

Book a consultation or read about accessibility audits.

I am a web accessibility specialist and ADA compliance consultant, a participant in the W3C Accessibility Guidelines Working Group and a DHS Trusted Tester. I am not an attorney and this is not legal advice. Speak to qualified counsel about your specific situation — I work alongside legal teams and provide the technical evidence they need. More about my background.