An accessibility statement is a public page on which you explain how accessible your website or app is, what doesn't work yet and how people can reach you if they get stuck. For public sector bodies, this statement has been mandatory since 2018, following a fixed model. Since 28 June 2025, many businesses, including online shops, also have to publish similar information under the European Accessibility Act.
This article is part of our complete guide to website accessibility. Here we focus only on the accessibility statement: what has to go in it according to the primary sources, where public sector and business rules differ, where to place it and how often to update it. You get a fill-in template that you can adapt straight away.
This explains the rules and is not legal advice. If you're unsure whether the rules apply to your business, or how far you need to go, ask a lawyer or the regulator.
What is an accessibility statement?
An accessibility statement is a document on your website in which you publicly disclose to what extent your digital service meets the accessibility requirements. It isn't a technical report and it isn't marketing copy. It's an honest account of where things stand for people who use your site with a screen reader, only a keyboard or magnification.
A good statement answers four questions. Which standard do you measure your site against? What doesn't work yet, and is there an alternative? How did you establish that, and when? And who can someone turn to if something doesn't work? In practice the standard is WCAG, the W3C guidelines. What levels A and AA mean exactly is covered in WCAG 2.2 explained.
The statement itself doesn't make your site more accessible. It does make it visible that you know where you stand. That is exactly what both the public sector rules and the EAA ask for.
Who is required to have an accessibility statement?
An accessibility statement is mandatory for public sector bodies under the Web Accessibility Directive, and for most service providers under the European Accessibility Act. The two regimes look alike, but they don't ask for exactly the same thing.
Public sector: model, register and status levels
Article 7 of the Web Accessibility Directive (EU) 2016/2102 requires public sector bodies to provide a detailed and clear accessibility statement that they update regularly. According to that article, the statement contains at least three things: which content is not accessible, with the reason and any alternatives; a feedback mechanism for reporting problems; and a link to the enforcement procedure.
The European Commission set out the model in Implementing Decision (EU) 2018/1523. That model includes a compliance status (fully, partially or not compliant), a list of non-accessible content, the date of preparation, the method used and contact details. As the method, the decision names a self-assessment or an assessment by a third party. It encourages reviewing the statement at least once a year.
In the Netherlands, the duty is set out in Article 4 of the Tijdelijk besluit digitale toegankelijkheid overheid (the temporary decree on digital accessibility for government). Public sector bodies publish the statement according to the minister's model and measure their site against the EN 301 549 standard. digitoegankelijk.nl explains how that works. You fill in the statement with an online assistant, and after publication it goes into the register. Each statement gets a status from A to E. A and B require a full accessibility audit, and those statements must be updated at least once a year. A C status is valid for six months.
Businesses: the information duty under the EAA
For businesses, Directive (EU) 2019/882 applies, the European Accessibility Act (EAA). Article 13 requires service providers to prepare information in line with Annex V and to explain how their service meets the accessibility requirements. That information must be available in written and oral form, including in an accessible way, and kept for as long as the service is offered.
Annex V says you include that information in your general terms and conditions or an equivalent document. Where applicable, it contains:
- a general description of the service, in accessible formats;
- the descriptions and explanations needed to understand how the service works;
- a description of how the service meets the accessibility requirements in Annex I.
In addition, Annex V allows you to apply harmonised standards, and you provide information showing that your service delivery process continues to ensure accessibility.
The Netherlands set this out for e-commerce in Article 6:230fb of the Dutch Civil Code, through the Implementatiewet toegankelijkheidsvoorschriften producten en diensten (the act implementing accessibility requirements for products and services). That article repeats the duty to prepare the information in line with Annex V and to make it available in written and oral form. Separate decrees exist for other services, such as e-books, communications services and passenger transport.
The ACM supervises e-commerce services and electronic communications services. According to the ACM, your website and app should include an accessibility statement that is easy to find and accessible itself. It describes how the service works with assistive technology and how you meet the rules. It must also be available orally, for example as an audio clip. As the standard, the ACM names WCAG 2.1 level AA, with the advice to start working with WCAG 2.2 now.
Micro-enterprises that provide services are exempt. According to Article 3 of the directive, that's a business with fewer than 10 employees and an annual turnover or balance sheet total of no more than 2 million euros.
Public sector and business side by side
| Public sector | Business under the EAA | |
|---|---|---|
| Legal basis | Directive 2016/2102, Dutch Tijdelijk besluit digitale toegankelijkheid overheid | Directive 2019/882 Art. 13 and Annex V; for e-commerce in the Netherlands, Art. 6:230fb of the Civil Code |
| Form | Mandatory model, fill-in assistant on toegankelijkheidsverklaring.nl | No fixed model; in general terms and conditions or an equivalent document |
| Mandatory content | Non-accessible content with reason and alternative, feedback mechanism, link to enforcement procedure | Description of the service, explanation of how it works, how you meet the requirements |
| Register | Yes, with status A to E | No |
| Standard | EN 301 549 | Annex I of the directive; ACM names WCAG 2.1 AA and recommends WCAG 2.2 |
| Updating | A and B at least yearly, C valid for six months | When the service, requirements or standards change (Art. 13(3)) |
| Available orally | Not as a separate requirement | Yes, in written and oral form |
| Supervision | Dutch Ministry of the Interior (monitoring) | ACM for e-commerce and communications services; other regulators per sector |
What goes into an accessibility statement?
A useful statement combines the mandatory elements of Annex V with the structure of the public sector model, because that model shows what visitors need. For a business, the obligation in Annex V takes precedence. The parts from the public sector model, such as status, limitations and method, make your statement concrete and verifiable.
Start with a short description of your service. What can someone do on your site: browse products, order, pay, manage an account? Then explain how the service works with assistive technology. Can someone operate everything with the keyboard? Does the checkout work with a screen reader? Are there login methods that require extra steps?
Then state the standard you measure against and the result. Be precise: "WCAG 2.2 level AA" is verifiable, "accessible to everyone" is not. Next, describe what doesn't comply yet, with an alternative and a timeline. Finish with the date and method of the assessment, contact options and the regulator.
Template for your accessibility statement
This template is a starting point for a business under the EAA and follows the elements of Annex V and the EU model. Replace everything in square brackets. Delete whatever doesn't apply to you, and don't fill in anything you haven't assessed.
# Accessibility statement [Company name]
[Company name] wants everyone to be able to use [website address] and [app name],
including people who use a screen reader, keyboard, voice control or magnification.
This statement applies to [website address] and [app name, if applicable].
## About our service
[Short description of the service: what customers can do here, for example
search for products, order, pay, create an account and get in touch.]
## How our service works
[Explanation of the main steps, for example: searching and filtering,
basket, checkout, payment methods, logging in, order confirmation by email.
Describe how these steps work with assistive technology.]
## How we meet the accessibility requirements
We measure our website against the Web Content Accessibility Guidelines (WCAG) 2.2,
levels A and AA.
Status: this website is [fully / partially / not yet] compliant with WCAG 2.2 level AA.
[For "partially" or "not yet": see the known limitations below.]
What we do to stay accessible:
- [for example: accessibility is part of design and development]
- [for example: we test every new feature with a keyboard and screen reader]
- [for example: responsible within the organisation: role or team]
## Known limitations
| Part | Problem | Alternative | Expected fix |
|---|---|---|---|
| [e.g. product filter] | [e.g. can't be used with a keyboard] | [e.g. search field or customer service] | [month and year] |
| [e.g. PDF manuals from before 28 June 2025] | [e.g. not tagged] | [e.g. other format on request] | [month and year or n/a] |
## How we assessed this
- Date of assessment: [date]
- Method: [self-assessment / assessment by [name of audit firm]]
- Approach: [for example: automated test with [tool], supplemented by manual
checks of [number] pages and the full order flow with keyboard and screen reader]
- Pages assessed: [list or description of the sample]
- Report: [link to report, if public]
## Contact and feedback
Are you running into a problem, or would you like this information in another
format or orally? Get in touch with us:
- Email: [email address]
- Phone: [phone number, with opening hours]
- Form: [link to accessible contact form]
We respond within [number] working days and will work with you to find a solution.
## Supervision
Not satisfied with our response? You can file a report with
[regulator, for example the ACM via ConsuWijzer: link].
## Date
This statement was prepared on [date] and last updated on [date].
A few choices in this template deserve some explanation. The sections "About our service" and "How our service works" come straight from Annex V. The status line and the table of limitations come from the EU model for public sector bodies and make your claim verifiable. The phone line is there because the EAA requires the information to be available orally as well.
Only choose "fully" as the status if an assessment backs it up. If you're not sure, write "partially" and list what you found.
Where do you place the statement?
Place the accessibility statement on its own page and link to it from the footer of every page. The EU implementing decision encourages public sector bodies to make the statement reachable from every web page, and the ACM asks businesses for a statement that is easy to find. The footer is where visitors and regulators look for it.
Use a clear URL and link text, such as /accessibility with the text "Accessibility" or "Accessibility statement". That helps people who go through a list of links with a screen reader. It also helps automated checks. Flowproof's accessibility check, for example, looks for a link with "toegankelijkheid" or "accessibility" in the link text or URL. A link that just says "More info" won't be recognised.
Annex V also mentions the general terms and conditions or an equivalent document. So refer to the statement page in your terms and conditions, or include its core there. If you have an app, put the statement or a link to it in the app too.
Make the page itself accessible. Use real headings, a table with header cells and plain HTML text instead of a PDF. A statement that can't itself be read with a screen reader defeats its purpose.
How often do you update the statement?
Update your accessibility statement at least once a year, and immediately after a major change to your site or service. The EU model for public sector bodies recommends a yearly review, and Dutch public sector bodies with status A or B are required to do so. For businesses, Article 13(3) of the EAA says you take account of changes to your service, to the requirements and to the standards.
Practical moments to review the statement:
- after a redesign, a new theme or a new checkout;
- when you add a new payment method, chat widget or login method;
- when you've fixed a reported limitation;
- when a standard changes, such as the move from WCAG 2.1 to 2.2;
- once a year, even if nothing seems to have changed.
Always put the date of the last review at the bottom. A statement that is three years old tells a visitor little about the site as it is today.
Common mistakes in accessibility statements
The most common mistake is claiming that your site fully meets WCAG without an assessment to back it up. A copied line saying "This website fully complies with WCAG 2.2 AA" is a factual claim. If it isn't true, you mislead visitors and hand a regulator an easy starting point.
Other mistakes that are easy to avoid:
- No way to get in touch. The public sector model explicitly requires a feedback mechanism, and the EAA requires oral availability. A generic contact form that is not accessible itself is not enough.
- Only tested automatically. Automated tools find some of the problems, not all of them. Keyboard operation, the logic of a checkout and understandable error messages need manual checking. How to approach that is covered in testing website accessibility.
- No date or method. Without a date and approach, nobody knows how reliable the statement is.
- Limitations without an alternative or timeline. For every known problem, say how someone can still proceed, and when you'll fix it.
- Hidden or impossible to find. A statement that can only be reached through the sitemap or a PDF is not easy to find.
- An overlay as proof. A widget that adjusts the display doesn't make the underlying code accessible. In your statement, describe what you've done to the site itself.
- Disproportionate burden without justification. If you rely on that exception, Article 14 of the EAA requires a documented assessment. According to the ACM, you also report this to the regulator.
How to check this on your own site
You can check in an hour whether your statement is there and whether it's correct. Go through these steps:
- Find the link in your footer. Open three random pages and check whether there's a link with "accessibility" or "accessibility statement" in the text or URL.
- Read the status critically. If it says "fully", look up the assessment that backs it up. If you can't find it, change the status.
- Check the Annex V elements. Is there a description of the service, an explanation of how the service works and a description of how you meet the requirements?
- Test the contact route. Does the email address work, can the phone number be reached and can the contact form be completed with the keyboard?
- Look at the date. If the statement is more than a year old, or older than your last redesign, schedule a review.
- Test the page itself. Use the Tab key to move through the statement and check the headings and tables.
- Run an accessibility scan. Flowproof's accessibility check is included in the paid Pro and Business plans. It tests your pages with axe-core against WCAG 2.2 levels A and AA and checks whether there is a link to an accessibility statement. You'll find the plans on the pricing page. Use the result as input for the "Known limitations" section, and supplement it with manual checks.
If you first want to know whether the EAA applies to your business, read the article on the European Accessibility Act. Still unsure after that? Ask a lawyer or the ACM.