An accessibility statement is the short public page where you tell users which accessibility standard your product follows, how close you are to meeting it, what still does not work, and how to reach you when something blocks them. Under the European Accessibility Act (Directive (EU) 2019/882), which applies from 28 June 2025, it is also the document a market surveillance authority will look for first when checking whether you take conformity seriously.
This guide breaks down the four parts a compliant accessibility statement must contain, with concrete wording you can adapt. It is written for the site and product owners assembling European Accessibility Act documentation, not for lawyers, so every section maps to something you can actually publish this week.
Why the EAA expects a statement at all
The EAA makes accessibility a conformity requirement. For in-scope digital products and services it means you must be able to *demonstrate* conformity, not just claim it. The accessibility statement is the user-facing half of that evidence: it states what your product does and does not do against a named standard, in plain language anyone can read.
The technical baseline is WCAG 2.2 Level A and AA, brought into EU practice through the harmonised European standard EN 301 549. A statement that references these specifically is far more defensible than one that vaguely promises to "care about accessibility." It also gives auditors, assistive-technology users, and your own team a fixed target to test against rather than a moving feeling.
One scoping note: microenterprises that provide services (fewer than 10 staff *and* under EUR 2,000,000 annual turnover) are largely exempt from the EAA's service obligations. If that is you, a statement is good practice but not mandatory for services. Most product manufacturers and larger service providers are firmly in scope.
The four things a compliant accessibility statement must include
1. The standard you follow
Name the exact standard and version. "This website aims to conform to WCAG 2.2 Level AA, as referenced by EN 301 549" is unambiguous; "we follow accessibility best practices" is not. Stating the version matters because criteria change between releases, and an auditor needs to know which checklist you measured yourself against.
2. Your conformance status
Use one of three honest labels: *fully conformant* (every applicable criterion is met), *partially conformant* (most are met, some are not), or *not conformant*. Be realistic. Very few real-world sites are fully conformant, and claiming it while a screen-reader user hits a broken checkout is worse than admitting partial status. A defensible statement reads: "This site is partially conformant with WCAG 2.2 AA. Partially conformant means some parts of the content do not yet fully meet the standard."
3. Known limitations
List the specific things that still fail, where, and what users can do instead. Vague disclaimers protect no one; specific ones build trust and limit your exposure. Tie each entry to the criterion it breaks, for example: "PDF invoices generated before 2024 are not tagged and may not read correctly in a screen reader (WCAG 1.3.1). Email support@example.com for an accessible copy." or "Some decorative-vs-informative image distinctions are still being corrected on legacy blog posts."
4. A feedback and contact mechanism
Give users a direct, monitored way to report a barrier, and commit to a response time (five working days is a common benchmark). Provide more than one channel where you can, an email and a phone number, so the contact route is not itself an accessibility barrier. This is the part regulators weigh heavily, because it is how a real person who is blocked actually gets help.
Worked example: a known-limitation entry done right
Compare these two. Weak: "Some content may not be fully accessible." Strong: "Colour contrast on our promotional banners currently measures 3.8:1 for body text, below the 4.5:1 required for normal text (WCAG 1.4.3). We are fixing this in the next design release; in the meantime the same offers are listed in plain text below each banner."
The strong version names the criterion, gives the measured value against the correct threshold (4.5:1 for normal text, 3:1 for large text of 18pt or 14pt bold and for UI components and graphics), explains the remediation timeline, and offers a workaround. That is exactly the level of specificity the EAA's "demonstrate conformity" expectation rewards.
How to gather the evidence behind your statement
You cannot write an honest conformance status without testing first. A practical order: run an automated scan to catch the obvious machine-detectable failures, then do manual checks for the things tools cannot judge, keyboard operability, focus order, meaningful alt text, and form labelling.
- Run a free pass with the AccessScan scanner to surface missing alt text, contrast failures, and unlabelled controls across your key pages.
- Walk through your top user journeys by keyboard, since checkout and sign-up are where barriers cost you customers.
- Confirm you have evidence for each WCAG principle: Perceivable, Operable, Understandable, Robust.
- Record the failures you cannot fix immediately. Those become your "known limitations" list, dated and tied to specific WCAG criteria.
Keep the testing notes. If a surveillance authority asks how you reached "partially conformant," your scan reports and manual test log are the proof behind the claim.
Publishing and maintaining the statement
Link your accessibility statement from the global footer so it is reachable from every page, and date it. An undated statement is treated as stale, and a statement that still lists a limitation you fixed six months ago reads as neglected. Review it whenever you ship a significant front-end change, and at minimum once a year.
If you would rather not start from a blank page, the accessibility statement generator assembles the four required sections into publishable copy you can edit, and the what to include in an accessibility statement guide goes deeper on the wording behind each section.