There is no fixed deadline for drawing up an accessibility statement. In practice, the process takes anywhere from a few days to several weeks, and that difference is almost always due to the same causes: how large the website is, whether scan results and an in-house assessment are already available, and how many components need to be reviewed manually because an automated scan cannot test them.
Anyone starting with a blank page — no scan, no overview of core pages, no understanding of the checkout step or login flow — spends most of the time gathering that baseline data, not writing the statement itself. Anyone who already has a current scan and a documented assessment can often complete the statement within a few working days. The statement is essentially a representation of work you have already done; the problem rarely lies in the document, but in what comes before it.
What determines the time it takes
Three factors consistently play a role. First, scope: an online shop with only a product catalogue is faster to assess than a platform with a checkout step, a login environment and a customer portal. Second, the starting position: is a quick scan already available, or does that still need to be carried out. Third, internal coordination: who within your organisation approves and signs off the statement, and how quickly that person is available. This last point is often underestimated — the substantive assessment is sometimes completed faster than internal approval.
Phase 1: establish scope and gather data
The first phase consists of determining which parts of your website or app fall under the directive and which core pages and flows should be included. For anyone who does not yet know whether the law applies at all, this is also the time to check that; find out in a few questions whether and where you fall under the directive gives you an initial picture of this, without requiring you to have an account.
Phase 2: what a scan can and cannot find
An automated scan reliably tests some WCAG criteria: colour contrast, missing alternative text, structural problems in the code. Other criteria — whether a form label is substantively correct, or whether the navigation order with only a keyboard is logical — require human review. This distinction is noted in every report, precisely because it affects the time it takes: the more components fall outside the automatically testable part, the more time the assessment takes before you can fill in the statement. The knowledge base sets out in detail per topic which criteria this affects; detailed explanation per topic of what a scan does and does not cover is a good starting point to estimate where your situation will take time.
Phase 3: draw up and publish the statement
Once the assessment is complete, drawing up the statement itself is usually the quickest part. The document follows a fixed format with a limited number of components: the current status, the components that do not yet comply, and how users can report an accessibility issue. Because the format can differ by country, it is advisable not to start from scratch for multiple countries each time, but to use a single underlying assessment as the basis. How that supporting information is assembled and documented can be read on how the underlying data is collected and documented.
Phase 4: keep it up to date after changes
The timeline does not end at publication. A declaration that was accurate at delivery can become outdated after a webshop update or a new step in the checkout flow. Many organizations underestimate this point: the first declaration takes the most time, but keeping it current is a recurring task, not a one-time effort. Those who want to delegate this process without having to handle it manually each time will find in what the subscription offers in terms of templates and reminders an overview of what is available for that purpose.
Where this runs into difficulties in practice
Most delays do not occur during writing, but at two moments: when it becomes apparent that the checkout step or login flow was not yet included in an earlier scan, and when no one internally owns the declaration. Both can be prevented by determining in advance who is responsible and which parts of the site fall under the assessment. For specific situations — a microenterprise, a platform serving only business customers, a site that has just been redesigned — slightly different principles apply; these are detailed per situation in the knowledge base and the answers to frequently asked questions.
If you want to know where you stand with your own website before planning a deadline, the free quick-scan is a logical starting point. It provides an initial indication based on a handful of core pages, without requiring you to create an account.