An accessibility statement is a public page that explains how accessible a website is, which parts do not yet meet the accessibility standard, what alternatives are available, and how a visitor can report a problem or ask for content in another format. It is usually linked from the footer of every page.
How an accessibility statement works
In the UK, the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 require most public sector bodies, such as central government departments, councils, NHS bodies and universities, to publish one in a set format and to meet the AA level of the Web Content Accessibility Guidelines (WCAG). At the time of writing (October 2026), the Government Digital Service monitors public sector sites against WCAG 2.2 AA, and GOV.UK publishes a sample statement to follow. Some organisations, including schools and nurseries, are partly exempt, so check the guidance for your type of body.
A good statement, public or private, covers:
- Compliance status: fully, partially or not compliant with WCAG at a stated level.
- Known problems: each one in plain words, ideally with the WCAG criterion it fails, such as text with poor colour contrast or images missing alt text.
- Plans and dates for fixing them.
- How to get help: an email address or phone number for reporting problems or asking for another format, and how quickly you will reply.
- How the site was tested, by whom, and when the statement was prepared and last reviewed.
Public sector statements must also explain the enforcement route: the Equality and Human Rights Commission in Great Britain and the Equality Commission for Northern Ireland.
Why it matters
For private businesses the regulations do not apply, but in Great Britain the Equality Act 2010 still requires service providers to make reasonable adjustments for disabled people, and that duty reaches websites. A statement does not discharge that duty by itself. What it does is show that you have looked, tell people where things stand, and give them a route to get what they need instead of leaving.
The practical case is just as strong. Many visitors use screen readers, zoom, keyboards instead of a mouse, or simply struggle with small grey text on a phone. Fixes that help them, such as clear headings, descriptive links and labelled form fields, tend to improve the site for everyone and support good SEO practice.
Common mistakes
- Copying a template. A statement claiming full compliance, copied from another site, is worse than none: it is simply untrue.
- Relying on an automated scan. Tools such as Lighthouse, WAVE and axe catch only some of the problems. Keyboard and screen reader checks find the rest.
- Treating an overlay widget as the fix. A toolbar added on top of the site does not repair the underlying code.
- Never updating it. A statement dated three redesigns ago tells visitors nothing.
- No working contact route Or one that nobody monitors.
How to act on it
Start with an audit against WCAG 2.2 at level AA: run an automated checker, then test the main journeys yourself with only a keyboard, at 200% zoom and with a screen reader such as NVDA or VoiceOver. List what fails, decide what you will fix and by when, and write the statement from that list. You can see how I set out mine in the accessibility statement for this site.
Link it from the footer, review it at least once a year and after any redesign, and log the requests people send through it. If an audit shows the site needs deeper changes to templates, colours or forms, that work fits naturally into a website redesign.