How to gut-check the scary accessibility email in your inbox, including ours

If you run an online store, you have probably had the email. Your website has accessibility problems, people with disabilities cannot use it, businesses like yours are getting sued. Sometimes there is a screenshot. Sometimes there is a deadline. It reads as somewhere between a public service and a shakedown, and you have no fast way to tell which. The thread about it on Shopify's community forum has been running since 2023.

We should know. We send emails like that. Ours name a specific failure on a specific page of a specific store, and before any of them goes out it has to survive three checks. Every one of those checks exists because at some point it caught a claim in our own draft that would have been false. This post publishes the checklist so you can run it against anyone's email. Including ours.

Check 1: does it reproduce on the page the email names?

Take the exact page the email points at and scan it yourself. Free tools are fine: axe DevTools, Lighthouse's accessibility pass, or our free scanner. Ours runs axe-core against any public URL and catches roughly 57% of WCAG issues, a baseline rather than a verdict, but plenty to confirm or deny one specific claim. If the email will not name a specific page, that is your answer already.

Two of our own near-misses show what this catches. A draft of ours claimed a broken carousel control appeared "on every product page I checked." Before sending we scanned a second product page, and the carousel did not even render there. The claim was true on one page and false as written, so it was rewritten to say exactly what we had observed. Another draft said a product gallery had eight unlabeled thumbnails. A fresh scan on send day found the count was really five thumbnails plus three other unlabeled buttons. Same total, different composition, and "eight thumbnails" would have been false. Rewritten.

The classic version of this failure is an email that cites your homepage while the real findings sit on product pages. We see the reverse often enough too: a homepage that scans clean and product pages that carry every critical issue. If you scan the page the email names and it comes back clean, the sender has not necessarily lied, but they have pointed at the wrong page, which means nobody checked before hitting send. Weight the rest of the email accordingly.

Check 2: does it survive the live page?

There are two versions of every page: the raw HTML the server ships, and the rendered page after every script has run. Accessibility claims built on the wrong one can be false in either direction, especially if you run an accessibility overlay, because overlays modify the rendered page.

Our own example: we once drafted an email around a store whose shipped HTML contained 29 images with no alt text. The store runs AudioEye, and with the overlay active, a scan of the live page found one. The overlay was genuinely patching the rest at runtime. Our claim was true of the HTML and false of the page any visitor actually experiences, so the email was never sent. Since then, every email about a store with an overlay is checked against a scan taken with the overlay running, and a screenshot of that scan goes in the file.

Do not assume the overlay is fixing things, though. On another store the overlay had been configured to be invisible, no button on desktop or mobile, and the colour contrast failures measured 14 with it switched off and 16 with it running. On a third, an app-store review said the store used an overlay, and the page contained no trace of it, no script and no widget, on first load or after clicking around. The overlay was gone and the review had outlived it.

The test for you: scan the live, rendered page, which is what any decent scanner does by default, and if you pay for an overlay, look at what it actually does to the findings rather than what its dashboard says. If an email's evidence looks like it came from raw source code, or the sender cannot tell you which version they scanned, they are describing a page your customers never see.

Check 3: is it your code?

A modern store page is a layer cake: your theme, the platform's own components, a review widget, a cart app, an analytics tag. Scanners flag the page; they do not tell you who owns the failure unless someone looks.

On one product page we scanned, four of the five findings, including the only critical one, belonged to the review widget and the platform rather than the store's own theme. An email that had called the critical one "a button on your site" would have earned a one line reply: that is not our code. It was rewritten to say which finding was whose.

Be careful with the comfort this check offers, though. Third party code on your page still fails your visitors and still shows up in complaints about your store, so "not our code" narrows the fix, it does not end the conversation. But a sender who cannot tell you which failures are yours and which are your apps' has run a scanner and stopped there, and you can do that yourself for free.

The shortcut red flags

Some emails fail faster than the ten minutes.

• A compliance guarantee. Anyone promising that a product makes you compliant is contradicted by the FTC, which in April 2025 ordered the overlay vendor accessiBe to pay $1 million and barred it from claiming its automated products can make any website WCAG compliant, or keep it compliant, without evidence to back the claim.
• "Not approved under WCAG." There is no approval body. WCAG is a technical standard, nobody certifies a site against it, and an email telling you your store "wasn't approved", especially one asking for admin access to fix it, is the pattern merchants on Shopify's forum correctly file under phishing.
• Threats from the wrong domain. Your platform will not warn you about a shutdown from a Gmail address or a look-alike domain. Merchants comparing notes on one such email got it right: check where it came from before you read what it says.
• Invented deadlines. There is no filing date bearing down on you by default.
• Vagueness. No page, no failure, no way to verify, no reason to reply.

Including ours

If the email that led you here was ours, it is short, plain text, and came from an address at getscreenmysite.com, our sending domain, which redirects to this site. It names one page on your store and one thing on that page a screen reader cannot read, says what that costs a shopper, and offers a hand audit at a fixed price. No links, no deadline, no compliance claim, and a line saying we will not email again if you tell us not to.

Run all three checks on it. The page is named, so check 1 takes two minutes. We run them after sending, too: days or weeks later we re-scan the page we named, and so far three stores have fixed the exact failure without ever replying. We do not claim credit for that, since we cannot know why the code changed, but the code changing is the only result we count.

If any claim of ours fails a check, reply and say so. We would genuinely rather know than get the sale, because every check on this list started life as an error we almost shipped.

---

This post describes how to verify technical claims. It is not legal advice, and if you have received an actual demand letter or complaint rather than a vendor email, speak to a lawyer.

Sources: FTC press release, final order against accessiBe (April 22, 2025) · Deque, automated testing coverage study · Shopify Community threads: Legal scam re: ADA compliance websites · I got an email from Vertex Agency Assistance · Scam or legit email