Website accessibility statement: what it must contain, with examples and a template

An accessibility statement is a public page on your website that describes how accessible your site or app is, which parts do not yet comply, what you are doing about it and where visitors can turn if they get stuck. For public bodies it is mandatory. For companies covered by the European Accessibility Act, it is the clearest way to meet the law’s information duty. In this article you read who needs a statement, what has to be in it and how to write one, with example passages and a template you can fill in straight away. This is guidance, not legal advice: when in doubt, have your situation checked by your lawyer.

What is an accessibility statement?

An accessibility statement is a document that summarises the accessibility of a website or app for the visitor. It is not a quality label and not a promise that everything works perfectly. It is an honest status report: which standard you follow, to what extent you meet it, which limitations remain and how someone gets help.

The W3C, the organisation behind the WCAG guidelines, lists in its guidance on accessibility statements three parts that belong in it at a minimum: a commitment to accessibility, the standard you apply and contact details for anyone who runs into problems. Known limitations, the measures you take and the technical requirements (such as supported browsers) are what make a statement genuinely useful.

Who has to publish an accessibility statement?

That depends on who you are and what you offer. There are two regimes, and they are often confused:

Public bodies: a mandatory model

Government organisations must publish a statement for every website and app. In the Netherlands this follows a mandatory model, drawn up via digitoegankelijk.nl (in Dutch) and its form wizard. The statement gets a status there from A (fully compliant) to E (no statement), and refers to an audit report and a plan for the open items. Belgian public bodies also work with a fixed model that refers to the EN 301 549 standard.

Companies: accessibility information under the EAA

Companies covered by the European Accessibility Act, such as webshops and consumer banks, have no mandatory model. The directive (Directive (EU) 2019/882, Annex V) does require you to explain publicly how your service meets the accessibility requirements. The Belgian FPS Economy makes this concrete in its guidelines for accessible e-commerce services (in Dutch): in your terms and conditions or an equivalent document, such as an accessibility statement, you must always:

• give a general description of the service;
• explain how the service works;
• state how you apply the accessibility requirements.

The FPS adds that you should explain both the possibilities and the limitations, and that this information must itself be accessible for as long as the service exists. Whether you fall under the law and which transition periods apply is covered in our article on the European Accessibility Act.

What belongs in an accessibility statement?

Combine the legal information duty with what the W3C recommends and you arrive at these parts. For a company under the EAA, the first six are the practical minimum.

1. Scope. Which website, subdomains or apps does the statement cover?
2. Description of the service. What can a visitor do, and how does it work: search, order, pay, return?
3. Standard applied. Usually WCAG 2.1 level AA, the standard incorporated in the European standard EN 301 549. If you already build to WCAG 2.2, say so.
4. Compliance status. Fully, partially or not compliant, with a short explanation.
5. Known limitations. Which parts do not comply yet, why, which alternative you offer in the meantime and when it will be fixed.
6. Contact and follow-up. Where someone reports a problem (email, phone, form), who follows up and within what time you respond.
7. How you tested. An internal review, an external audit, automated tools and manual tests, with the date of the last test.
8. Technical requirements. Which technologies the site relies on (HTML, CSS, JavaScript) and which browsers and assistive software you tested with.
9. Date. When the statement was drawn up and last updated.
10. Complaints route. Where someone can go if you do not respond. In Belgium, for webshops and banking services, that is the Economic Inspection of the FPS Economy.

Accessibility statement examples

The passages below are examples we wrote for an imaginary webshop, to show what a good section looks like in practice. They are not copied from an existing site.

Example: a known limitation in a “partially compliant” statement

Product videos published before June 2025 do not have captions yet. Each video has a written description of the product on the same page. We will add captions to all product videos by March 2027.

Why it works: it names the exact problem, offers an alternative today and commits to a date.

Example: a contact block that actually helps

Can’t complete an order or find the information you need? Email accessibility@ourshop.example or call +32 3 000 00 00 (weekdays 9:00 to 17:00). We confirm your message within two working days and help you place your order another way if needed.

Why it works: two channels, opening hours, a response time and a concrete promise, instead of a general info address.

Example: a description of how you tested

Last review: 14 September 2026, by our own web team. We used automated checks on all page templates and tested the full order process manually with keyboard only, NVDA on Firefox and VoiceOver on Safari for iOS.

Why it works: a visitor can see how recent and how thorough the claim is.

Template: accessibility statement for a company website

This template is meant for a private website or webshop. Replace everything in square brackets and delete what does not apply to you. Have the final text checked by your lawyer if in doubt, especially if you fall under the EAA.

Accessibility statement

[Company name] wants everyone to be able to use [website address],
including people with a visual, auditory, motor or cognitive
disability.

Which website does this statement cover?
This statement covers [website address] and [any subdomains or apps].

What can you do on this website?
On this website you can [view, order and pay for products / book an
appointment / manage an account]. [Short description of the process:
search, basket, checkout, returns.]

Which standard do we follow?
We test this website against the Web Content Accessibility Guidelines
(WCAG) 2.1, level AA, as incorporated in the European standard
EN 301 549.

How accessible is the website?
This website is [fully / partially / not] compliant with WCAG 2.1
level AA. [Short explanation.]

What does not work yet?
- [Part]: [problem]. Alternative: [for example ordering by phone or
  email]. Planned fix: [month and year].
- [Part]: [problem]. Alternative: [...]. Planned fix: [...].

How did we test?
Last review on [date], by [our own team / an external party], using
automated tools and manual tests with keyboard and screen reader on
[browsers and assistive software].

Stuck?
Report it via [email address], [phone number] or [form]. We confirm
your report within [number] working days and look for a solution
together.

Not satisfied with our response?
[Belgium, webshops and banking services:] You can file a complaint
with the Economic Inspection of the FPS Economy.

This statement was drawn up on [date] and last updated on [date].

Put the statement on its own page, for example /accessibility/, and link to it from your footer so it is reachable from every page. Refer to it from your terms and conditions as well. Make the page itself accessible, of course: real headings, a readable font size and no PDF as the only version.

Which mistakes do you see often?

Most statements do not fail on form, but on credibility. These are the patterns we come across most often:

• A copied text without a test behind it. A statement claiming “fully compliant” while the contact form has no labels undermines trust faster than an honest “partially”.
• No working contact point. A general info address that nobody follows up is not a reporting channel. Say who follows up and within what time.
• Limitations without a plan. Naming open items is fine, but without an alternative and a date it is an excuse.
• Never updated. After a redesign, a new payment module or a new theme, last year’s statement is no longer accurate.
• An overlay as proof. Mentioning an accessibility plugin as if it guarantees compliance is misleading. Plugins rarely solve structural problems in your code.

Which errors a test usually exposes is covered in our overview of the most common web accessibility mistakes.

How do you gather the information for your statement?

You only write a statement once you know where you stand. Start with a quick scan of your most important pages, for example with our WCAG checker, which shows automatically detectable errors on your homepage, a product page and a form. Add a manual test: navigate using only the keyboard, let a screen reader read out your order process and zoom in to 200 percent. What each WCAG criterion means and who in your team owns it is set out in our WCAG 2.1 AA checklist.

The limitations you find become the “What does not work yet?” list in your statement. You plan the fixes following the step-by-step plan in our guide to website accessibility for your existing site.

Frequently asked questions

Is an accessibility statement mandatory for companies?

Not as a separate document. Companies under the European Accessibility Act must, however, describe publicly how their service works and how they apply the accessibility requirements, in their terms and conditions or an equivalent document. An accessibility statement is the most common and clearest form for that.

Can I use a generator?

Yes, as a starting point. The W3C offers a free accessibility statement generator, and Dutch public bodies use their own form wizard. A generator creates the structure, but the content (status, limitations, contact) has to come from your own test.

How often should I update the statement?

At least once a year, and immediately after every major change to your website, such as a redesign, a new theme or a new payment module. Show the date of the last update visibly at the bottom.

What if my site is not compliant yet?

Then write that down honestly. A statement with the status “partially compliant”, a list of known limitations, alternatives and planned dates is more credible than a promise that is too good to be true, and shows you are taking accessibility seriously.

The short summary

An accessibility statement tells visitors honestly how accessible your website is, what does not work yet and where they can turn. Public bodies follow a mandatory model; companies under the EAA must describe in their terms or an equivalent document how their service works and how they apply the accessibility requirements. Use the examples and the template above, fill them in based on a real test and update them after every major change.

Want to know where your website stands today and what belongs in your statement? See how we handle the audit, the fixes and the statement on our WCAG compliance page, or contact us.