The directive itself does not specify a fixed deadline for "making" a web shop accessible. What is fixed is the date on which the obligation applies: since 28 June 2025, the requirement is enforceable for services that fall within its scope. How long the actual process takes to move from a current website to one that complies with EN 301 549 (in practice WCAG 2.1 level AA) depends on the size of the site, the number of barriers, and how quickly an organisation can make internal decisions.
In practice, a project breaks down into four phases: audit, prioritise, remedy, and document. A small web shop with a standard CMS theme and a limited checkout typically moves through these phases faster than a platform with a custom login environment, bespoke checkout, and multiple languages. There is no single timeframe that applies to every organisation; there is, however, a pattern in where projects encounter delays.
What the regulation covers and what it does not
The regulation describes which services fall within scope, which technical standard applies, and what information an accessibility statement must contain. A specific deadline for 'scan first, then improve within X weeks' is not set out. Supervisory authorities look at the current state of a service and whether an organisation demonstrably and systematically works towards compliance, not at a fixed implementation time that would be the same everywhere. For the precise requirements for each element of a site, it is advisable to consult the official text itself; we have identified what the rules precisely mean for each topic and where they appear in the official text.
Where projects get stuck in practice
The first delay often does not arise from the technology but from the overview: companies do not know which pages, forms and flows fall within scope and which do not. A second barrier is the checkout step and the login environment; these are often custom components not included in a standard theme and therefore do not automatically benefit from a CMS update. A third barrier is dependence on an external provider for the CMS or payment module, where a change sometimes has to wait for a release from that party. A fourth barrier is internal: a list of findings in technical language sits unused because no one knows who is responsible for which item.
Four phases and where they stall
The audit phase establishes what is not working, on which pages, and how serious it is for someone using a screen reader or keyboard only. This is the phase where an automated scan does the most work, but also the phase where it must be clear what such a scan cannot detect; not every WCAG criterion can be tested automatically.
The prioritisation phase turns findings into a sequence: what blocks a purchase completely, and what is a minor inconvenience. This often stalls because a technical findings list does not say who within the organisation is responsible for which part.
The remediation phase is the phase with the longest duration, and how long it takes depends heavily on whether adjustments can be made in-house or must go through a supplier. Form labels and colour contrast are often quick to fix; a checkout that technically cannot be operated with keyboard alone requires more development work.
The final phase is documentation: drawing up the accessibility statement, setting down an improvement plan with deadlines, and demonstrating that an internal assessment has been carried out. This is not a phase you skip once the technology is right; the statement should reflect the current state, even if that state is not yet perfect.
What does affect the timeframe
An organization that knows in advance which pages fall within scope and which bottlenecks carry the most weight loses less time shuttling back and forth between technical teams and decision-makers. In a few questions you can see for free where a site currently stands, without needing an account for that. For what comes next — the full scan of the checkout process and login flow plus a prioritized action list in plain language — the detailed breakdown per requirement with corresponding deadlines is part of the paid engagement; what it contains is laid out clearly in one overview.
One final factor that affects the timeline: accessibility is not a project with an end date but a state that applies anew after every change to the site. A new checkout step or a refreshed contact form can bring back a problem that was already solved. Anyone wanting to know where the information in a report comes from and how often it is updated will find that on the page that explains how the process works.
For your own situation, with your own CMS, vendor and internal planning, it remains difficult to name a hard deadline in advance. Anyone unsure whether an engagement can be realistically planned should first get clear on exactly what needs to happen before building a schedule around it. The free quick-scan is a logical starting point for that, without immediately requiring an account or payment.