To substantiate your own assessment of accessibility, you need three types of documentation: an overview of what you tested and when, the findings per page or component, and a record of what was done with those findings. Together, these documents demonstrate that the accessibility statement is not pulled out of thin air, but rests on a review that you have carried out or had carried out.
The detail that matters most on this topic is the scope of that review. An automated scan can test a large part of the EN 301 549 requirements, but not everything: whether alternative text is substantively correct, whether the reading order for a screen reader is logical, or whether an error message in a form is actually understandable — these are matters that a scan cannot establish with certainty. A file that contains only a scan report without naming that limitation presents a distorted picture of how thorough the testing has been.
Why this documentation matters
The accessibility statement itself is a short, public document. What lies behind it — the substantiation — is what counts when someone asks how you arrived at that statement. This could be a supervisory authority, but also a customer who reports a page that does not work with a screen reader. In both cases, it is convenient if you do not have to reconstruct from scratch what happened.
What should be in the file
A basic file typically contains the following: the date and scope of each test, including which parts of the website or app were included, such as the checkout process, the login flow, or a specific form. In addition, the findings themselves, per page or function, ordered by severity so it is clear what was tackled first. Furthermore, an overview of the actions that resulted from this, with a status: resolved, in progress, or deliberately postponed with a reason. Finally, a note on the method: automated, manual, or a combination, and which parts fell outside the scope of the scan.
The point that is often overlooked
Many organisations keep a scan report, but not the note about what was not tested. It is precisely that missing piece that a supervisory authority or an attentive user will ask about first: was there only an automated review, or was it also verified that the site works with keyboard only and with a screen reader? A file that explicitly states where the boundary of testing lay looks more convincing than a file that suggests that everything was tested when that was not the case. provides a more precise picture of how a scan is conducted and where its limits lie than a single report can suggest.
Recording is not the same as complying
Keeping these documents is not an end in itself and does not replace the substantive improvement of a website or app. An overlay widget that claims to automatically ensure accessibility does not produce any of these documents that will hold up to substantive scrutiny, simply because the underlying problems have not been solved. Recording has value only if it reflects a genuine process of testing and improvement.
When this file is needed
Whether you need to be able to show this file depends on whether your organisation falls within the scope of the law and what exemptions apply to it, such as the exemption for micro-enterprises providing services. To determine whether that applies to your situation, the scope check is a logical starting point, and for the broader background you can consult the knowledge base with explanations per situation consult. Those who, in addition to the record, also want to see the underlying obligations with deadlines per country will find that in the explanation of what the subscription adds.
Would you first like to know where your site or app currently stands before you start building a file? do the free quick scan of a few core pages and then read carefully which documents are relevant for your situation.