Accessibility Statement for EU Client Sites: What Agencies Should Publish

What Is an Accessibility Statement?

An accessibility statement is a published web page — or a clearly labelled section of a page — that declares the accessibility status of a website or digital service. It tells users with disabilities what the site can and cannot do for them, how to get help if they encounter a barrier, and what the organisation is doing to fix known problems.

Under Directive 2016/2102 on the accessibility of the websites and mobile applications of public sector bodies, a formal accessibility statement has been mandatory for EU public-sector bodies since 2019. Every government website, university portal, and public utility must publish one in a prescribed format. Non-compliance has already resulted in enforcement actions across Germany, France, the Netherlands, and Austria.

For private-sector sites, the picture changed when the European Accessibility Act (EAA — Directive 2019/882) became applicable on 28 June 2025. The EAA covers e-commerce services, banking, transport booking, and several other digital service categories. Its harmonised technical standard, EN 301 549, explicitly references the accessibility statement as a conformance evidence mechanism. Several member-state transpositions — including Germany (BFSG) and France — have made the statement an explicit legal requirement for covered private-sector services.

Even where not yet mandated by statute in a particular jurisdiction, publishing an accessibility statement is now considered baseline professional practice. It signals to users, clients, and regulators that the organisation has assessed its site, understands its current state, and is actively managing accessibility as an ongoing commitment rather than a one-time checkbox. Absence of a statement is itself a red flag in any regulatory investigation.

For web agencies, this creates a concrete deliverable: after every audit, the client should leave with a statement draft that is accurate, specific, and legally defensible. That is not what most agencies currently provide. Most clients either have no statement at all, or they copied a generic template that claims full conformance the site demonstrably does not have.

The 8 Sections an EU-Compliant Statement Must Have

The European Commission's model accessibility statement (published under the Web Accessibility Directive) and subsequent EAA guidance define a consistent structure. A compliant statement should contain all eight of the following sections.

Honest Statements vs. Template Statements

There are dozens of accessibility statement generators online. Most produce a page that says something like: "We are committed to ensuring digital accessibility for people with disabilities. This website is fully conformant with WCAG 2.1 Level AA." Then they list no specific issues, no testing methodology, and no contact route that actually reaches a human.

These template statements fail for three reasons.

They claim conformance the site does not have

Automated tools catch 30–40% of WCAG failures. A site that has never been manually audited almost certainly has issues not visible to scanners: keyboard traps, screen reader confusion on dynamic content, focus management failures in modals and single-page application routing. Claiming full conformance on such a site is a false statement — one that regulators and litigants can test by running their own assessment.

In Germany, the Bundesnetzagentur has already sent formal notices to organisations whose accessibility statements claimed full conformance while automated checks revealed obvious failures. The statement itself became the evidence of bad faith.

They list no known limitations

An accessibility statement with an empty known-limitations section is a red flag to any regulatory inspector. Real sites have issues — every organisation knows this. A statement that pretends otherwise signals either that no assessment was conducted, or that the organisation knows about issues but is hiding them. Neither interpretation is helpful in an enforcement context.

Counterintuitively, listing known issues is a legal protection, not a liability. It demonstrates that the organisation has assessed its site, understands the current state, and is managing remediation. Regulators give significantly more credit to organisations with detailed, honest statements than to those with no-issue boilerplates.

Audit-backed statements are materially different

A statement generated from a real audit can do what a template cannot: reference specific issues with WCAG criterion codes, name the affected page templates, specify the remediation timeline by phase, and link to the full audit report for verification. This level of specificity is precisely what national supervisory authorities are looking for when they assess whether an organisation is making a genuine effort.

When your agency delivers an audit, one of the highest-value outputs you can include is a pre-populated accessibility statement draft that the client can review, adapt, and publish. It demonstrates professional thoroughness, reduces the client's legal exposure, and positions your agency as the ongoing partner for keeping that statement accurate.

Language to Avoid — and Language to Use

The words used in an accessibility statement carry legal weight. Here is a practical reference for what to avoid and what to use instead.

The "Partially Conformant" status is a strength

Many clients resist "partially conformant" because they read it as an admission of failure. Help them understand that this is the honest, legally correct status for virtually every real-world website. A partially conformant statement with a detailed known-limitations section and a credible remediation plan is far stronger — legally and reputationally — than a "fully conformant" claim that any automated scan will immediately contradict.

Regulators do not expect perfection. They expect transparency, ongoing effort, and a functioning feedback mechanism. A well-written partial conformance statement demonstrates all three.

Specific issue language

When describing known limitations, specificity is your friend. Compare these two approaches:

The strong version is what an audit report already contains. When your agency runs an audit through AccessiProof, every issue is tagged with its WCAG criterion and its affected page template — exactly the information needed to populate this section of the statement.

Why Pairing a Statement with Monthly Monitoring Makes It Stronger

An accessibility statement is not a one-time document. Its legal and practical value depends heavily on being kept current. A statement last reviewed two years ago, referencing an audit conducted three years ago, provides almost no protection in an enforcement context — the site may have changed dramatically since then.

Monthly monitoring solves this problem systematically. Here is how the pairing works in practice:

For agencies building a recurring revenue model around accessibility, the statement pairing is the mechanism that ties the initial audit to the ongoing retainer. The audit produces the statement draft. The monitoring retainer keeps the statement accurate. Clients understand this value chain instinctively once you explain it in those terms. See our guide on selling accessibility retainers for specific pricing and positioning strategies.

How to Generate a Statement from Audit Data

The best accessibility statements are not written from scratch — they are generated from the audit itself. An audit already contains everything the statement needs:

• Issue list with WCAG mappings — becomes the non-accessible content section with criterion codes and affected page templates
• Remediation roadmap — becomes the expected fix dates by issue, showing regulators that a plan exists
• Overall compliance score — maps directly to one of the three compliance status declarations (fully / partially / non-conformant)
• Standards tested — the WCAG version and EN 301 549 reference can be pulled from the audit methodology, pre-populating the technical specification and assessment approach sections
• Browser and AT testing matrix — the assistive technologies used in manual testing populate the technical specification section directly

AccessiProof's Accessibility Statement Draft Feature

After completing a paid audit in AccessiProof, the dashboard provides an Accessibility Statement Draft that pre-populates all eight required sections from the audit data. The output is a structured HTML document the client can publish directly to their /accessibility page, or review and adapt if they have additional context to add (such as their preferred enforcement authority link for their specific jurisdiction).

The draft is not AI-generated marketing copy. It pulls structured data directly from the audit: issue identifiers, WCAG success criterion numbers, affected URL patterns, severity levels, and remediation phase assignments. The result is a statement that can be verified against the audit report itself — which is exactly what a regulator would want to do.

After each monthly monitoring cycle, the dashboard flags any changes to the known-limitations list — new regressions detected or existing issues resolved — and prompts an update to the statement. This keeps the two documents in sync without requiring manual reconciliation.

Where to Publish the Statement

The location of the accessibility statement matters. EU guidance specifies that it must be "easily discoverable" — in practice, this means it should be reachable from any page on the site without more than two or three clicks. The most common and recommended approaches are:

Discoverability is part of the requirement

Publishing a statement at a correct URL but hiding it in a sub-menu that only appears on the privacy policy page is insufficient. The test regulators and auditors apply is simple: can a first-time user navigating the site with a screen reader find the accessibility statement without specific prior knowledge of its location? A persistent, clearly labelled footer link passes this test. A link buried three levels deep in a mega-menu does not.

How Often to Update the Statement

The EU Web Accessibility Directive and the EAA guidance both specify that the accessibility statement must be reviewed and updated regularly. "Regularly" has a minimum definition: at least annually. In practice, this minimum is often insufficient.

When to update

• After every new audit — if you run a new audit, the statement must be updated to reflect the current findings. An outdated statement that contradicts a current audit is worse than no statement.
• After significant site changes — a new site redesign, a new checkout flow, a new CMS integration, or a major feature launch can all introduce new accessibility barriers or resolve existing ones. Either outcome requires a statement update.
• When issues are resolved — each time a known limitation from the statement is fixed and verified, it should be removed from the list and the last-reviewed date updated. Progress is a story worth telling.
• When new issues are discovered — if a monthly scan identifies a new regression, it should be added to the known-limitations section promptly. Waiting until the annual review to add a known issue that has been sitting in the monitoring dashboard for six months is not defensible.
• At minimum, annually — even if nothing material has changed, the statement must be reviewed, confirmed as still accurate, and the review date updated. A statement with a review date more than 12 months old is a compliance weakness regardless of its content.

Monthly monitoring creates a natural update cycle

For clients on a monthly monitoring retainer, the statement update cadence can be built into the monthly reporting workflow. After each monthly scan, the monitoring report arrives. The agency reviews it for any changes to the issue list — new regressions detected, existing issues closed — and pushes a statement update if anything has changed. The review date is updated regardless.

This creates a virtuous cycle: the monitoring produces the data, the data updates the statement, and the statement demonstrates ongoing compliance management. For EU regulators, this is the ideal pattern — an organisation that reviews its accessibility status monthly and documents the results is demonstrating exactly the kind of systematic compliance effort the EAA is designed to encourage.

For agencies, monthly monitoring with an included statement refresh is a compelling service proposition. The client gets legal protection and a current accessibility statement without having to manage the review process themselves. The agency gets recurring revenue and a strong argument for renewal: "Your statement has been reviewed every month this year. Three issues have been resolved. Two new regressions were caught and fixed before they required updating the statement. This is what proactive compliance management looks like."