A statement built from your results, not a template.
Every claim in it traces to a check your team answered and accepted. When the results change, the statement re-versions, and the version a reader saw last month is still there.
The statement is the first thing anyone reads.
- A template claims a conformance level nobody assessed.
- The version on the site names a WCAG release from years ago.
- Procurement asks for the link, and the honest answer is that it is out of date.
- The app is not mentioned at all, because the audit only covered the website.
- Nobody can say which audit the claim came from.
A statement is a claim about your product. It should be produced by the thing that assessed it.
Check. Accept. Publish. Re-version.
The statement is an output of the audit, so it is only ever as current as your results.
Check
Your team answers the guided checks for each page or screen, against the standards you are held to.
Accept
A person on your team accepts every finding. Nothing reaches the record, or the statement, without that.
Publish
The statement is generated from those results, with conformance status, known limitations, feedback route and enforcement details.
Re-version
Fix something and re-check it, and the statement re-versions. Earlier versions stay available.
A statement you can point a buyer at.
- Conformance status against EN 301 549 and WCAG, taken from your own audit.
- The known limitations, in the reader’s words rather than a standard’s.
- A feedback route and the enforcement details a regulator expects.
- Coverage for iOS and Android apps, including Chapter 11, on the paid plan.
- A statement of intent from the day you start, if the audit is not finished.
- Version history, so you can show what you claimed and when.
Who this is for.
- Teams whose buyers or procurement ask for the statement link.
- Public sector suppliers and bodies with a published statement to keep true.
- Anyone whose current statement was written from a template.
Not for
A certificate. It is a statement of what you found and what is still open, which is what a reader is checking.
The rest of accessibility.
What people ask.
Do we need an accessibility statement?
Do we need an accessibility statement?
If you sell a digital product or service to EU consumers, the European Accessibility Act expects one, covering websites and apps. UK public sector bodies have had the same duty since 2018. Buyers and procurement teams ask for the link whether or not a regulator has.
What has to be in it?
What has to be in it?
Conformance status against EN 301 549, the parts that are not accessible, any alternatives you offer, how someone reports a problem to you, and the enforcement route. The generated statement carries all of them.
Can we use a template instead?
Can we use a template instead?
You can, and plenty do. The risk is that a template claims a conformance level nobody assessed. This one is built from the verdicts your team recorded, so the claim and the evidence are the same thing.
How does it stay current?
How does it stay current?
Fix something, re-run the checks for what changed, and accept the findings. The statement re-versions from those results, and the previous versions stay available.
Does it cover iOS and Android apps?
Does it cover iOS and Android apps?
Yes, against EN 301 549 including the Chapter 11 requirements WCAG does not cover. Apps are on the paid plan; auditing a website is free.
What if we have only just started?
What if we have only just started?
You can publish a statement of intent when you start the audit: it says what you are assessing and by when. It is honest about where you are, which is what a reader is checking for.
Want a statement you can stand behind?
Start free on one website, and the statement comes from the audit your team runs. Or bring the one you have published to a 30-minute call, and we will tell you what it would take to make it true.