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.

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.