An accessibility statement is a public page that tells people how accessible your website or app is: which standard you test against, how far you meet it, what is known not to work, and how to report a problem or ask for content in another format. It’s written for the people who use your site, and they usually read it when something has already gone wrong.
It isn’t the same as an accessibility policy. A policy is the internal commitment and the governance behind it: who owns accessibility, which standard the organization adopts, and how work is tested and signed off. The statement is the public account of where that work stands today.
Do you need an accessibility statement?
That depends on who you are and where you operate. For some organizations a statement is a legal obligation with prescribed content. For everyone else it’s good practice.
| Who | Requirement | What it asks for |
|---|---|---|
| EU public sector bodies | Required by Article 7 of Directive (EU) 2016/2102, the Web Accessibility Directive | A statement for each website and app, following the Commission’s model in Implementing Decision (EU) 2018/1523, kept up to date |
| UK public sector bodies | Required by regulation 8 of the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 | A statement that follows the government’s model accessibility statement, kept under regular review |
| US federal agencies | Required by OMB policy in memorandum M-24-08 | A digital accessibility statement on agency websites. This is an OMB management requirement, separate from the technical Revised 508 Standards |
| Service providers covered by the European Accessibility Act | An information requirement under Article 13 and Annex V of Directive (EU) 2019/882 | An explanation of how the service meets the accessibility requirements, in the general terms and conditions or an equivalent document. The Act doesn’t call it a statement, and microenterprises providing services are exempt |
| US state and local governments | Not required by the ADA Title II web rule | The rule sets WCAG 2.1 Level AA as the technical standard but doesn’t require a statement. A statement is still a practical place to tell users how to report a barrier |
| Everyone else | Not usually required | Still the clearest way to tell users what to expect and where to report a barrier |
This table is a summary, not legal advice. National laws can add to these requirements, so check the rules where you operate.
What to include in an accessibility statement
The required wording differs by jurisdiction, but a statement people can use covers the same core elements.
- Scope. Which websites and apps the statement covers. Write one statement per website or app, and give the version and date for apps.
- The standard you test against. Name the version and level, for example WCAG 2.2 Level AA. Where a law applies, it sets the level for you. EU public sector bodies, for example, follow EN 301 549, which uses WCAG Level AA for web content.
- Conformance status. Say whether the site is fully conformant, partially conformant or non-conformant, in those words. Saying a site is partially conformant is more credible than claiming a full conformance you can’t demonstrate.
- Known limitations. What doesn’t work yet, who it affects, why, and the accessible alternative. Add a plan or a date for fixing it where you have one.
- How you assessed it. The evaluation method and when it was done: self-assessment or external audit, automated and manual testing. Automated checks find only part of what WCAG covers, so pair them with manual review. Web accessibility quick fixes: A content creator’s checklist covers what that review should look for.
- Feedback and contact. How to report a barrier or request content in another format, who receives it, and how quickly you’ll respond.
- Dates. When the statement was prepared and when it was last reviewed.
The W3C’s guidance on developing an accessibility statement describes the same elements in more detail.
If you’re an EU or UK public sector body
Your statement has to follow the model statement, which adds three things to the list above. Compliance status is stated as fully, partially or not compliant with the standard the law names. Each piece of non-accessible content gets a reason, and only three count: non-compliance, a disproportionate burden, or content outside the law’s scope. And the statement links to the enforcement procedure users can turn to if your response doesn’t resolve their problem. The EU Web Accessibility Directive FAQ covers these obligations in full.
An example accessibility statement
Here is a short statement for a fictional organization. Replace everything in brackets.
Accessibility statement for example.org
[Organization] wants everyone to be able to use example.org. This statement covers example.org and its subdomains. Our mobile app has its own statement.
Conformance status: example.org is partially conformant with WCAG 2.2 Level AA. Some content doesn’t yet meet the standard.
Known limitations: Some PDF reports published before [year] aren’t tagged for screen readers. Contact us and we’ll send an accessible version within five working days. Videos on our events pages don’t have captions yet, and we expect to add them by [date].
How we tested: Automated monitoring of the whole site, plus manual review of key tasks using a keyboard and a screen reader, last completed on [date].
Feedback: Email [accessibility contact] or call [number]. We reply within five working days.
This statement was prepared on [date] and last reviewed on [date].
Each part does a job. The scope stops users assuming the app is covered, the limitations name the content and the workaround, and the dates show whether the statement still describes the site. To build a complete statement step by step, use the accessibility statement generator.
What should your accessibility statement sound like?
With so many things to consider above, it may be tempting to give your accessibility statement the feel of a legal document.
Don’t.
Technical jargon will only add confusion and deny your statement the chance to benefit your users. Instead, treat your web accessibility statement as you would a value or mission statement. Be open and candid with your users. Let them know where you shine in accessibility and don’t try to cover up any challenges users may experience on your site – they can’t hide forever.
It’s also important that you explain any flaws of your website in common terms instead of legal rules. If your photos lack captions, say that. Don’t cite the guideline you’re failing to meet. Remember that users simply want to understand what’s possible and not possible for them on your site, not check it against statute.
The most common mistakes undo that candor. A claim of full conformance with no scope or test date reads as a promise nobody checked. A list of failed success criteria by number tells users nothing about what they can’t do. A missing contact route or response time leaves people with nowhere to go. And a statement with no review date gives no way to tell whether it still describes the site. Burying the page in a sub-menu defeats the rest.
Make it easy for users to find your web accessibility statement
A hidden accessibility statement might as well have never been created. Make sure yours is read by putting it somewhere prominent on your website. Link it from the footer of every page, or from your home page, and make sure the page itself is accessible and mobile-friendly. Publish it as a web page, not only as a PDF.
Once you’ve published your accessibility statement, review it at least once a year, and again after a redesign, a major release or a new app version. EU and UK public sector bodies should also line reviews up with national monitoring. In the EU, member states report on monitoring every three years.
Read more on the EU Web Accessibility Directive and the European Accessibility Act.
