How do you prove to a regulator that you take accessibility seriously?

Short answer. No website is 100% perfectly accessible at every moment, and a regulator does not expect that either. What counts is whether you can demonstrate that you maintain your site structurally and verifiably: a record of scans, errors found, points resolved, and the dates of each. That is your reasonable-effort evidence. An overlay widget cannot provide this; continuous testing with a keepable record can.

Does a regulator demand perfection?

No. In practice, enforcement comes down to one question: are you taking this seriously, and can you show it? A site that is measurably and continuously improved stands far stronger than a site with no trace of effort, even if both still have a few open points. The key is demonstrability: not just doing it, but being able to show it.

What belongs in a good accessibility record?

A useful record shows the timeline of your effort:

• Timestamps of every scan, when did you test?
• Per finding, the WCAG criterion involved and where on the page it failed.
• The status of each point: found, resolved, re-checked.
• The progress over time, the line that shows you are structurally improving.

This is exactly the difference between "I thought it was fine" and "here is the proof that I am on top of it."

Why can an overlay widget not provide this?

Because an overlay does not repair your code and builds no reliable improvement trail. The layer changes on each page view and leaves the real errors in place, so there is nothing to demonstrate except that you bought a widget. And that does not help you: sites with a widget are targeted for lawsuits. The numbers are in sued despite an accessibility widget.

Does this also apply under the European Accessibility Act?

Yes. The European Accessibility Act requires online stores and digital services in the EU to meet EN 301 549 / WCAG 2.1 AA. In the event of a complaint or audit, you want to be able to show that you test and repair your site continuously. A keepable record is then not an administrative burden but your line of defense, and at the same time a reassurance to your customers.

And in the US, where no regulator comes knocking?

In the United States the test usually does not come from a regulator at all, it comes from a plaintiff's attorney. The American Bar Association estimates that businesses received 35,000 to 50,000 pre-litigation demand letters in 2025, most of them sent by a small group of serial-plaintiff firms before any lawsuit is filed.

The logic of the record is exactly the same, only the audience changes. When a demand letter arrives, the first thing your attorney wants to see is a dated remediation dossier: when you tested, what you found, what you fixed, and when. That is the documentation of a good-faith, structural effort, built before the letter arrived, not scrambled together after it. A widget purchase receipt proves nothing about your code; a scan-and-fix history does.

This article is informational, not legal advice, consult an attorney for your situation.

How do I build such a record?

At its core: measure, fix, document, repeat.

1. Test your site at the source-code level and record the result.
2. Fix the errors found in your own code.
3. Keep the history, every scan, every fix, with a date.
4. Keep testing continuously, so new changes do not break something unnoticed.

Scan your site for free to see where you stand today. That is the first line in a record that, when it matters, speaks for you.