An accessibility statement describes the state of affairs at the moment you publish it. If something changes on your website — a new checkout step, a different form, a refreshed menu — then in practice what that statement covers also changes. If you don't retest afterward, the statement will fall behind the actual site in terms of content. This is not a technical formality: the statement is intended to show what you have checked and what you have not, and that picture simply no longer holds true if unchecked components have been added.
What happens concretely is this: new or modified parts of your website have never been assessed against the requirements in EN 301 549. Potential issues — a missing label on a new form field, a button that only works with a mouse, a color contrast that just doesn't meet the standard — remain unnoticed until someone encounters them or until testing is done again. The statement itself remains on paper in the meantime, but no longer fully covers the actual situation.
Why this is not a one-time project
The underlying thinking behind the Directive is that accessibility is a property of the service, not of a single snapshot. A webshop, app, or business environment is constantly changing: new products, an updated checkout, a different login flow, a new type of content on the blog. Any change can in principle affect components that previously met the requirements. This is why regulators, when assessing compliance, do not just look at whether a statement exists, but also at how current it is compared to the site as it functions now.
For an SME organization, this practically means that testing and publication are not a completed project, but part of how you handle changes to your website. Anyone building a new page or having a supplier place a widget would do well to ask themselves whether that component has been assessed before — and if not, whether it still needs to be.
What is commonly overlooked in practice
The most common situations where a statement silently falls behind are recognizable: a webshop adds a new payment method with its own separate screen, an HR department puts a job application form from an external party on the site, or an office application receives an update from the supplier in which buttons and menu structure change. None of these changes feels like a major project, but each one introduces new screens that do not automatically fall under earlier testing.
Internal reorganizations also count: a new style guide that adjusts button colors, or a content management system that switches to a different editor for alt text. These kinds of changes are rarely linked to the question of whether the existing statement still applies, simply because they don't feel like 'the website' but rather like a minor update.
What regulators look at
Regulators assess in their own way by member state, and the precise approach varies. Broadly speaking, it can be said that a statement that is outdated in content — for example because it describes an older version of the website — does not align well with the purpose of the statement, namely to provide a current and traceable picture of your own assessment. Whether and how that is assessed in any particular case is up to the competent regulator and, where necessary, up to a lawyer to clarify.
This is also why axessia.eu indicates with every scan what has and has not been tested automatically: an automated check covers part of the requirements, and this is stated in every report. An overlay widget that promises to solve this retroactively does not fulfil the underlying obligation — that is one of the few things we state without reservation.
How to implement this in practice
A workable approach is to link testing to your own change process rather than to a fixed calendar date. Every time a new step, a new form or a new type of page is added, that is a natural moment to check whether that component has already been included. For smaller organisations, it is often more practical to link this to larger changes — a new payment system, a new supplier for the login screen — than to every individual text adjustment.
To see how your current site is performing, you can find out in a few questions where you stand now. Anyone who wants to understand how such an assessment is built up exactly and where the information comes from will find that explained under how we build the scan and the report. For the broader explanation of declarations, assessments and what comes with them, the knowledge base where this is explained by topic is a logical starting point, and specific questions about your own declaration often come up under frequently asked questions about the declaration.
Want to know if your latest changes have already been included? The free quick-scan gives you a first indication within a few minutes, without needing to create an account.