An accessibility statement template: what to write, and how to back it up
Two documents get confused in the same conversation. A client asks for "an accessibility statement" when what they need is an audit — or asks for an audit, gets it, and then discovers the buyer wants a statement published on the site, a document nobody scoped. They are not the same document, they are not written for the same reader, and one can be published without the other, which is exactly how statements end up making claims nobody can check.
The rule this whole page runs on: write the statement from the record, never the record from the statement. The statement is a public claim about a site, written for the people who use it. The record is the dated test behind that claim, written for the person who has to defend it. Get the order wrong and you end up testing backwards from a sentence you already published.
1. What each document actually is
An accessibility statement is one public page, in plain language, addressed to users: what works, what doesn't, how to report a problem, who to complain to if the answer isn't good enough.
An audit report is a dated record of a test, addressed to the client and their developer: what was tested, when, by what method, what was found, which criterion each finding breaks, what is still open.
W3C draws the boundary where it belongs: statements "are not technical assessments or declarations of conformity, though they ideally refer to such background to provide verification and increase credibility." That last clause is this entire page. Refer to the background — and have a background to refer to.
None of this is legal advice. Which rules bind your client depends on their country, their sector and their size, and that is a question for their lawyer rather than their web developer.
2. Does the client actually need a statement?
Sometimes yes, legally. Often no, but usefully. Occasionally they are asking for the wrong document entirely, and saying so early is the most valuable thing you do that week.
| What is happening | What they need | What you hand over |
|---|---|---|
| Public sector body in a country that implements the EU Web Accessibility Directive | A statement is required | The statement, citing the test record |
| UK public sector body | A statement is required, alongside meeting WCAG 2.2 AA | The statement, citing the test record |
| Procurement questionnaire from an enterprise buyer | Evidence that the thing was tested, usually a VPAT or ACR | The report; a statement helps, but it is not the ask |
| Private site, no legal duty, disabled customers | Nothing is required, but a statement is cheap and useful | A statement written from whatever was actually tested |
| Client wants proof the work was done | A dated record | The report |
| Client wants a badge for the footer | Neither | Say so, kindly |
GOV.UK puts the UK test in two halves, and both matter. A site will "meet the legal requirements" if it meets "the Web Content Accessibility Guidelines (WCAG) 2.2 AA accessibility standard" and publishes "an accessibility statement that explains how accessible your website or mobile app is". A statement on its own is not the requirement. A statement about an untested site is a document that says nothing.
3. The six parts, in the order a user reads them
A user arrives at a statement because something already went wrong for them. They are looking for their own problem, so the order matters more than the prose.
- Scope. One sentence naming the site, the domains and any app version. Users need to know the statement covers the thing they are on.
- What works. Specific and checkable, in user terms: text can be zoomed, most of the site works by keyboard, a screen reader can read the main content.
- What doesn't work. The honest list, most impact first, in plain language, each item with a plan and a date.
- How to report a problem. A contact route a person actually monitors. Not a form that goes nowhere.
- Who to complain to. The escalation route. In the UK this wording is fixed by regulation; GOV.UK's sample marks it "legally required and must not be changed".
- Technical information. The standard tested against, the compliance status, and the date of the last test.
Do not carry a template across borders. The EU directive and the UK regulations each prescribe content, and a UK sentence pasted into an EU statement can be wrong in both. GOV.UK's sample statement is the clearest worked example of a required structure — it is explicitly fictional, which makes it safe to learn from. W3C's statement generator is free and asks for the same information in a jurisdiction-neutral way. Read both before writing a word.
4. Compliance status is a claim, so decide it from the record
Most statements fail here, because "compliant" is the one word a template will happily fill in for you.
GOV.UK's wording notes are precise about the three options: fully compliant if the site meets WCAG 2.2 AA in full, partially compliant if it meets most requirements, not compliant if it does not meet most. The middle two are the normal outcome of a real audit — our judgement, not a measured rate — and a partially compliant statement that names its gaps is worth more to a disabled user than a fully compliant one that nobody tested.
| What you can write | What has to be true | What you need to have done |
|---|---|---|
| "Fully compliant with WCAG 2.2 AA" | Every page in scope, every template, every state, against every AA criterion | A full manual audit across the site, dated |
| "Partially compliant", with the gaps named | Most requirements met; each gap listed with its criterion and a fix date | A real audit covering every template you claim |
| "Not yet assessed" | Nothing | Nothing — but say when it will be |
| "Accessible", with no standard and no scope | Nothing | Nothing. This is the sentence that starts an argument. |
The last row is the one to delete from any template you inherit.
5. Where the audit report earns its place
A statement's weakest line is its compliance claim, because it is the only line anyone will ever test. The report is what makes that line checkable: which page, at what moment, by what method, with what result, and what is still open.
The two documents interlock at three points. The report's finding row — element, issue, WCAG criterion, severity, fix — becomes the statement's "what doesn't work" entry, rewritten for a user. The report's scope line becomes the statement's scope sentence. The report's date becomes the date on the statement. Everything else in the report stays in the report: nobody reading a statement wants a severity taxonomy.
The honest consequence is a limit on what a statement can claim. A report on one page supports a statement about one page. If the client's site has five templates, a statement claiming the site is partially compliant needs five tests behind it, or it says which template it covers and which it does not. The part you cite is the coverage section, including what it could not test — that is the sentence that makes the rest believable. For what belongs in the report itself, the audit report guide covers it; for the order to run the test in, the accessibility audit checklist does.
6. Translate the finding, don't paste it
W3C's guidance is blunt about register: rather than "WCAG Success Criterion 1.2.2 was not met", write "videos do not have captions". Criterion numbers belong in the record. The statement is for people trying to use the site.
| In the report | On the statement |
|---|---|
| Images missing a text alternative (1.1.1) — how to write alt text for images | "Some images have no text alternative, so screen reader users miss the information in them." |
| Form fields without a label (3.3.2) | "You can use the contact form with a keyboard, but some fields are not announced clearly by screen readers." |
| Link text "read more" (2.4.4) | "Some links say 'read more', which is confusing when read out of context." |
| Positive tabindex values (2.4.3) | "On some pages the Tab key moves in an order that does not match what is on screen." |
| Duplicate ids (4.1.2) | "Some form labels point at the wrong field, so a screen reader may read the wrong label." |
Keep severity out of the statement. A user does not care whether a defect is serious or moderate; they care whether they can do the thing they came for. Severity belongs in the fix queue.
7. Publish it where people look, and keep it true
- Put it on a page reachable from every page — a footer link, not a PDF. A PDF sits outside the site's own navigation and is only as accessible as the export that produced it.
- Date it, and say what it was based on.
- Update it when you fix something or when the template changes. A statement two releases old describes a site that no longer exists.
- If a claim cannot be backed, remove it. Deleting an over-claim is a fix, not a retreat.
- GOV.UK's note on the summary section is the best editing rule in this whole area: "If you're not confident that something is accurate, leave it out."
8. What this page cannot tell you
- Which rules apply to your client. Country, sector and exemptions decide that. A lawyer answers it, and no template substitutes for the answer.
- Whether the site is compliant. A statement records a claim; it does not test anything. Automated checks catch only a minority of real accessibility problems, so a clean scan is a floor, never a result.
- Whether the statement is complete. One page is not a site audit. If the record covers one template, the statement can only speak for that template.
AuditReady produces the record half of this pair — 12 deterministic HTML checks on one page, every finding carrying its WCAG 2.2 criterion and a fix, laid out as a report you can cite. It does not write the statement, and it is not a compliance certificate.
A statement is a promise to the people using the site. A report is what you keep, so that a year later the promise is still true.
Written 1 November 2026.