If you report an accessibility issue yourself to the market surveillance authority — for example because you discovered a shortcoming yourself and want to make known that you are working on it — you typically need four things: a concrete description of the problem, supporting evidence that demonstrates the problem, a reference to your existing accessibility statement, and an improvement plan with deadlines that states what you will do and when. That is a different set of documents than the statement itself, and that difference is precisely where things often go wrong.
An accessibility statement is a fixed, annually updated publication that describes how your site or app currently stands. A report is something different: it concerns one specific problem, at one specific moment, and requires a file that makes that problem demonstrable and shows that you are taking action on it. Those who confuse the two often submit a statement where a market surveillance authority expects a plan, or vice versa.
Why a report requires something different than the statement
The statement is a snapshot of your entire site: which parts comply, which do not, and what the reason is. A report concerns a single shortcoming that has been flagged, for example because a customer has indicated they cannot complete the checkout process with a screen reader, or because you found this yourself during an internal test. The market surveillance authority then does not want to see your full statement again, but specifically: what is the problem, how do you know this, and what will you do about it. That requires a more precise and compact file than the annual publication.
This detail matters most here: a report without an improvement plan with a deadline looks like an acknowledgment without follow-up. It is not the description of the problem that makes the difference, but the presence of a concrete date by which the solution will be ready. Without that date, a report remains a statement of intent rather than a demonstrable step.
The components of a complete file
A problem description should mention which page or function is involved, which WCAG requirement appears to be at issue, and how the problem was identified: reported by a user, found during an internal test, or flagged by an automated scan. Supporting evidence typically consists of a screenshot, a short video of the operation, or a technical explanation of the element that is not working properly. The reference to the existing statement shows that this is not a standalone incident, but part of an ongoing process in which you have already taken stock previously. And the improvement plan finally describes the step being taken, who is responsible for it, and by what deadline it will happen.
These four components together form the minimum. What a market surveillance authority expects beyond that varies by country and by situation, and that is also where the limit lies of what a platform like axessia.eu can fill in for you: we establish, prioritize and flag, but the final assessment of your file rests with the competent market surveillance authority or, if you are in doubt about your specific situation, with a legal advisor.
What a market surveillance authority does with the report
Market surveillance authorities typically treat a report as a signal, not as an endpoint. They check whether the described problem has been made credible, whether the organization is visibly working on it, and whether the stated deadline realistically matches the nature of the problem. A small piece of text without alternative description requires a different timeframe than rebuilding an entire checkout process. That is precisely why the improvement plan belongs with the report, and not as a separate follow-up document that still needs to come later.
Keep documentation as you go to avoid rushing things later
Organizations that only start gathering evidence when a specific complaint arrives will find that reconstructing the situation is harder than documenting it at the time. When was the problem first noticed, who reported it, which version of the website was live at that moment – these are questions that are difficult to answer after the fact if nothing was recorded when it happened. A running file containing findings, screenshots and action items by date makes submitting a complaint a matter of summarizing rather than investigating. In the knowledge base by topic explains how such a file relates to the mandatory declaration and the improvement plan that goes with it.
Where to file this
Whether a complaint is required for your organization at this moment depends on your situation: whether you fall within the scope of the legislation, which parts of your website or app have been tested, and what those tests revealed. A few questions give you a direct indication of where you stand, and also show which parts an automated test cannot assess. For the precise form and associated complaint format per country, axessia.eu refers you to the market surveillance authority itself; what we provide is documenting the file so you don't have to reconstruct what happened from scratch each time a complaint comes in.
Are you uncertain whether your situation calls for filing a complaint, or would you like to first know what such a file looks like in practice? Do the free quick scan or browse answers to questions that other business owners have already asked before you take any action.