How to write an accessibility statement that says what you checked
An accessibility statement is a short page that says which standard you aim for, what you actually checked and how, which problems you know about, and how someone can tell you about a barrier and get the information another way. Its value is honesty: a specific list of known gaps is more useful, and more defensible, than a claim of full compliance.
Who needs one
This is practical guidance, not legal advice. In the UK, public sector bodies must publish an accessibility statement under the 2018 accessibility regulations, as GOV.UK's guidance explains. In the EU, the European Accessibility Act covers e-commerce among other services, so check whether it applies to your business. For many small private businesses a statement isn't strictly required, but it's still worth writing: it shows customers you've thought about them, gives them a way to reach you, and forces you to test your own site.
What goes in it
The W3C's guidance on accessibility statements recommends at minimum a commitment, the standard you follow and contact details, and suggests known limitations, how you tested and any technical requirements. A small business statement can work through these headings:
- Our aim
- One or two sentences: that you want everyone to be able to use the site, and the standard you work towards, usually WCAG 2.2 level AA.
- How we checked
- What you tested, when and how: keyboard-only navigation, a screen reader pass, zoom to 200%, a contrast check, an automated scan. Name the tools and the date.
- What works
- Specific things you confirmed, such as every image having a text alternative, forms having labels, focus being visible.
- Known problems
- Each gap in plain words, where it is and what you're doing about it, with a date if you have one.
- Other ways to reach us
- Phone, email or in person, so nobody is shut out of a booking or enquiry by a barrier on the site.
- Report a problem
- How to tell you, what to include and how quickly you'll reply.
- Last reviewed
- The date the statement was checked against the site.
Write it, step by step
Here's how to write an accessibility statement from your own tests rather than from a template.
- Test the site before writing a word. Use the 15-minute check in making an AI-generated site accessible: keyboard, zoom, screen reader, contrast and an automated scan.
- Write down every problem you found, however small, with the page it's on.
- Fix what you can now. Faint text, a missing label and vague link text are often quicker to fix than to describe.
- Draft the statement under the headings above, describing only what you actually checked. The W3C's free statement generator can produce a first draft to edit.
- List the remaining gaps honestly, including content you don't control, such as a third-party booking page you link to or PDFs from a supplier.
- Give a real contact route that someone reads, and a response time you can keep.
- Publish it as its own page and link it from the footer of every page, next to your privacy policy.
- Set a reminder to re-test and update it at least once a year and after any big change.
What not to claim
- "Fully compliant with WCAG" unless a thorough audit against every success criterion says so. Automated tools catch only part of what WCAG covers.
- "Accessible to all users". No site is; say what you aim for and what you've checked.
- Overlay widgets as a solution. Toolbar add-ons that promise compliance don't fix the underlying page and can get in the way of assistive technology users' own settings.
- A template with someone else's details or tests you didn't run. A statement that's obviously copied undermines the rest.
What Anticode checks, and what you still check
You can describe these honestly in your "How we checked" section. Anticode's design gate blocks publishing a page that lacks a language, a phone viewport, visible keyboard focus, reduced-motion support or alt text. Sentinel fails a page if a form field has no label or an image has no text alternative, and the Critic flags body text below 16px. Those are automated checks of the page's code. They don't confirm that alt text describes the image accurately, that your own colour choices keep enough contrast, or that the page makes sense read aloud, so test those yourself and say you did. Anticode pages declare English as their language; if your content is in another language, note it as a known issue, since screen readers may mispronounce it. Anticode writes a privacy policy and terms for each site but not an accessibility statement, and its optional pages are a fixed set, so publish the statement as an entry in a CMS collection, which gets its own address, or as a section on your About page.
Checking the statement itself
Read it with a screen reader turned on: it should be as easy to use as you claim the site is. Ask someone outside the business to follow the "report a problem" instructions and see whether the message reaches you. Then put the review date in your calendar and keep it current; an out-of-date statement is worse than a short, honest one.
Questions people ask
Does a small business need an accessibility statement?
Often not by law, unless you're a public body or a rule such as the European Accessibility Act covers your service. It's still good practice and cheap to do well.
Can I use a template?
Yes, as a structure. The W3C generator is a good start. Replace every line with what's true for your site and your tests.
How long should it be?
A page. Specific and short beats long and vague. Most of its length should be the known problems and how to reach you.