Got an ADA website demand letter? What to check in the first 72 hours (technical side only)

AI Client Discovery — Thu, 12 Nov 2026 02:34:52 +0000

If your small business just received a letter claiming your website violates the ADA, this is the technical half of what to do in the first 72 hours. The legal half belongs to a lawyer — get one before the deadline in that letter. What follows is the evidence side, which is the part most owners have nobody for.

You are not an edge case. Law firm Seyfarth Shaw counted 3,117 federal website-accessibility lawsuits filed in 2025, and for every filed case there are more demand letters that settle quietly. Most defendants are small businesses, and most cases start the same way: somebody ran an automated scan of your site and printed what it found.

Step 1 — Preserve everything, starting now. Save the letter and note its deadline. Screenshot your key pages with dates (home, contact, booking or checkout, your top service pages). If you fix things later, this dated "before" state is what proves the timeline.

Step 2 — Run the same kind of scan they ran. Free tools (WAVE, axe) will show you the usual findings in minutes: images with no alt text, form fields with no label, buttons a keyboard user can't reach, text with too little contrast, videos with no captions, a checkout that can't be completed without a mouse. Automated tools only catch part of the problem — but they're the part a plaintiff's scan catches too, so they're where you start.

Step 3 — Fix the source code, not the surface. An overlay widget is not a fix: in 2025 the FTC ordered the largest overlay vendor to pay $1 million over claims its product made sites compliant, and sites with overlays installed keep getting sued. The fixes that count are in the page itself — labels, alt text, focus order, contrast — done by you or your developer.

Step 4 — Document the work like evidence. Keep dated before/after scan results and a dated log of what was fixed, where, and when. Whatever happens next — settlement talks, a response through your lawyer — runs on this paper trail.

Step 5 — Re-scan and keep the records. A dated re-test after fixes closes the loop and is your proof of good faith.

One boundary worth knowing: there is no official "ADA certificate" for a private website, and nobody can sell you one. Courts and DOJ settlements use WCAG 2.1 AA as the benchmark — that standard, not a stamp, is what an audit should measure against.

I run AI Client Discovery. We do human-verified WCAG 2.1 AA audits for small businesses: the scan, a plain-language fix list your developer can apply, and the dated evidence pack your lawyer can work from. We don't give legal advice. If you're staring at one of these letters, the technical evidence is the part we can take off your plate — questions welcome in the comments, or at aiclientdiscovery@gmail.com.

Webhook signature verification fails even though the secret is right

AI Client Discovery — Thu, 12 Nov 2026 01:41:56 +0000

Reproduced in my own test setup — not a client's, and no real account involved:
a Stripe-style webhook keeps failing signature verification even though the
signing secret is definitely right. Posting the reproduction because the cause
turned out to be a one-line pipeline mistake, and the error message gives you
no hint which side is wrong.

The setup: a test endpoint receives the webhook, parses the JSON body, then
verifies the HMAC signature. Secret copied straight from the dashboard, event
after event, verification fails every time.

What actually breaks it: the signature is computed over the exact bytes that
arrived, not over "the same JSON". My handler parsed the body and then
re-serialized it before verifying — pretty-printing plus sorted keys. Same
payload, same secret, different bytes, different signature. I confirmed it
with a local check: signature over the raw body verifies; signature over the
re-serialized body does not. Nothing was wrong with the secret at all.

The fix, in order:

Capture the raw request body as bytes BEFORE any JSON parsing, and verify the signature against those bytes only. In most frameworks that means reading the raw body / disabling the JSON body parser on the webhook route. Only after verification passes, parse the body and process the event. If your platform parses the body for you before your code runs (some no-code webhook steps do), check whether it offers a "raw body" output — if it doesn't, verify at a step that still sees the raw payload, or move verification to a small endpoint that does.

How to tell this apart from a genuinely wrong secret: compute the HMAC
yourself over the raw bytes you actually received (log them once, exactly as
received) and compare with the signature header. If your hand-computed value
matches the header, the secret is right and something downstream is
re-writing the body — that is this bug. If it doesn't match even over the raw
bytes, then the secret (or the timestamp tolerance, if the sender enforces
one) is the problem, and no amount of re-formatting will help.

One gotcha while testing: don't "verify" by re-sending from a tool that
re-serializes the payload for you — you'll reproduce the failure and conclude
the secret is wrong. Test against the exact bytes the sender sent.

DEV Community: AI Client Discovery

Got an ADA website demand letter? What to check in the first 72 hours (technical side only)

Webhook signature verification fails even though the secret is right