How to write an accessibility statement, with an example for the European Accessibility Act
Gideon Awolesi ·
If you sell to consumers in the EU, the European Accessibility Act requires you to publish how your service meets the accessibility requirements. A lot of companies do that with an accessibility statement page. A statement that only says the company is committed to accessibility doesn't help a customer with a disability use the service. Below are the parts a useful statement has, and a full example with placeholders for your own details.
01What to include
Under Article 13(2) and Annex V of the Act, you have to describe the service, explain how it works, and explain how it meets the accessibility requirements. You also have to show how you keep it compliant as you change it. The EU's model statement for public sector websites adds the parts customers look for first: what isn't accessible yet, and how to get help.
- A short description of the service.
- How people with disabilities can use it, like with a keyboard or a screen reader.
- The standard and version you tested against, and how well the service meets it.
- How you test new features and changes.
- The parts that aren't accessible yet, and when you plan to fix them.
- An email address for accessibility problems, and how quickly you reply.
- Where people can complain if they're not happy with your reply.
- The date you prepared the statement and the date you last reviewed it.
If you sell into Germany, the BFSG also requires the name of the market surveillance authority responsible for you.
02An example statement
This is the kind of statement our accessibility statement generator writes. Replace everything in square brackets with your own details, and only keep the claims you've actually tested.
Accessibility statement for [Your shop]
[Your company] wants everyone to be able to use [Your shop] (www.example.com), including people with disabilities. This statement describes how the service meets the accessibility requirements of the European Accessibility Act (Directive (EU) 2019/882).
About the service
[Your shop] is an online shop where you can browse products, pay by card or bank transfer, and track your orders.
How you can use the service
- Every page and feature works with a keyboard alone.
- It works with screen readers, like VoiceOver, TalkBack, and NVDA.
- You can zoom to 200% without losing content or functionality.
- Form fields have labels, and errors explain how to fix them.
How the service meets the accessibility requirements
We design and test [Your shop] against WCAG 2.2 level AA. The service partially meets these requirements. It was last tested on [date] by [tester], using manual testing with a keyboard and a screen reader and automated testing.
Known limitations
- The product image zoom can't be opened with a keyboard. You can see the same images at full size on the product page.
- Order confirmation PDFs aren't tagged for screen readers. The same details are in your confirmation email.
We plan to fix them by [date]. If you need any of this content in another format in the meantime, contact us and we'll help.
Feedback and contact
If you find an accessibility problem, or you need information from the service in another format, email us at [accessibility@example.com]. We aim to reply within 5 business days.
This statement was prepared on [date] and last reviewed on [date].
03How to write the known limitations
The known limitations section is where a customer with a disability finds out which parts of your service they'll have trouble with, and the other way to do the same task. A vague limitation doesn't help them plan around it. Name the feature, say who's affected, and give the alternative.
Some parts of the website may not be fully accessible.
The product image zoom can't be opened with a keyboard. You can see the same images at full size on the product page.
04Common mistakes
- Claiming the service fully meets WCAG when it's only been checked with an automated tool. Automated tools find a part of the problems, so if you haven't tested by hand, say the service partially meets the standard.
- Naming WCAG without a version or level. Write WCAG 2.2 level AA, or the exact EN 301 549 version you tested against.
- Publishing the statement as an image or a scanned PDF, which screen reader users can't read.
- Leaving out a contact address, so people who run into a problem can't get help.
- Never updating it. When the review date is two years old, customers can't trust that anyone has checked the service since.
05Where to publish it and how to keep it up to date
Under the Act, the information belongs in your general terms and conditions or an equivalent document. Publish the statement as a normal web page, link to it from your footer and from your terms, and make sure the page itself meets the standard it describes.
Then review it when you release a significant change, like a new checkout or a redesign, and at least once a year. The once-a-year review comes from the EU's recommendation for public sector statements, but it's a sensible rhythm for a private company too. Update the review date each time, so customers can see it's current.
You can write a first draft with our free accessibility statement generator, which runs in your browser. If you'd like us to do the testing behind it, our Accessibility Audit covers up to five key journeys by hand against WCAG 2.2 AA in two weeks, from €5,500, and includes a draft accessibility statement.