Information checked: 21 July 2026.
An accessibility statement should explain the accessibility of a website honestly, identify known barriers and give users a practical way to request help or report a problem. It is not a marketing badge and should not claim full compliance unless the organisation has evidence for the stated scope and standard.
In brief: Describe what was tested, what remains difficult, how to obtain an alternative and when the statement will be reviewed.
Who needs a statement?
Covered public-sector bodies are required by the Public Sector Bodies accessibility regulations to publish and maintain an accessibility statement. Other organisations may choose to publish one as good practice, to explain reasonable adjustments or because a contract requires it. The exact legal position depends on the organisation and service, so obtain qualified advice where necessary.
What a useful statement contains
| Section | What to explain |
|---|---|
| Scope | The website, subdomains, applications or documents covered by the statement |
| Standard and method | The WCAG version and level used, pages sampled and testing methods |
| Known limitations | Specific barriers, affected journeys and any available alternative |
| Contact route | How to report a barrier or request information in another format |
| Response process | Who receives requests and the realistic response arrangement |
| Preparation and review | When the statement was prepared, last reviewed and next due for review |
Write limitations clearly
Avoid broad statements such as “some pages may not be accessible”. Name the component or task, describe the effect on the user and explain the available alternative. Do not promise an accessible PDF, telephone service or staff response unless that route has been tested and resourced.
- Distinguish content the organisation controls from third-party services.
- Explain disproportionate-burden decisions only where the relevant framework allows and the assessment has actually been completed.
- Do not hide serious barriers behind technical language.
- Record the owner and target date for each planned improvement.
Keep the statement operational
- Test the published contact route.
- Review the statement after significant redesigns or platform changes.
- Update it when a known barrier is fixed or a new one is discovered.
- Compare the statement with the current accessibility backlog.
- Retain evidence of testing and decisions.
Acceptance check
A statement is ready when a user can understand the scope, known barriers, available alternatives and contact process, and the organisation can support every claim with current evidence.
Keep published information aligned with reality
An accessibility statement becomes misleading when fixes are deployed, new barriers appear or the contact mailbox is no longer monitored. Link the statement review to release management and the accessibility backlog rather than relying only on an annual reminder.
Records to keep
- Statement owner and review trigger.
- Current test report and known-issue register.
- Alternative-format process and response evidence.
- Publication and revision history.
Owner test: Send a test barrier report through the published route and confirm that staff recognise, record and respond to it appropriately.
Sources and date checked
This practical guidance was checked against the following primary sources. Legal duties depend on the organisation and service, so obtain qualified advice where the consequences are significant. Date checked: 21 July 2026.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.