Accessibility Statements: What Goes In and What Often Goes Wrong

Scroll to the footer of almost any European website these days and you’ll find a link labelled “Accessibility” or “Accessibility statement”. Click it, and you often get very little: a couple of sentences about “striving to make our site accessible”, a generic email address and sometimes a date from 2020. That doesn’t help anyone – not the people trying to find out whether they can use the service, and not the organisation trying to meet its legal duties.

On top of that, the terminology is confusing. Public sector bodies in the EU have to publish an accessibility statement. Businesses covered by the European Accessibility Act (EAA) – in Germany, the Barrierefreiheitsstärkungsgesetz or BFSG – have to publish information on how their service meets the accessibility requirements. People often call both an accessibility statement, but they follow different rules. This article untangles the two, shows you how to structure the page and covers the mistakes worth avoiding. We use the German rules as our main example, since that’s where the details are most concrete.

Please note: this article provides general information as of October 2026 and is not legal advice. For a binding assessment of your situation, talk to a qualified lawyer.

Two duties, two legal bases

The accessibility statement comes from the EU Web Accessibility Directive (Directive (EU) 2016/2102), which covers websites and mobile apps of public sector bodies. Every member state has transposed it. In Germany, the federal rules are in section 12b of the Disability Equality Act (BGG) and section 7 of the BITV 2.0 regulation. The German states have their own laws with similar, though not always identical, requirements.

The accessibility information for services comes from the European Accessibility Act (Directive (EU) 2019/882). It applies to private providers of consumer services such as online shops, e-ticketing or banking apps. The directive sets out the required content in its Annex V; Germany’s BFSG mirrors this in section 14 and Annex 3. For more on who the German law covers, see our article on the BFSG.

Both documents share one goal: transparency. People should be able to find out up front how accessible a service is, where the barriers are and who to contact. But the required content differs quite a bit.

The accessibility statement for public sector bodies

Required content

Under section 12b BGG, a German federal body’s statement must include three things:

• Content that isn’t accessible: which parts are not fully accessible, why not, and whether accessible alternatives exist.
• A feedback mechanism: a directly reachable, accessible electronic contact option that people can use to report barriers and request information.
• A reference to the conciliation procedure: an explanation that people can request conciliation under section 16 BGG, with a link to the conciliation body.

Section 7 of the BITV 2.0 adds detail. The statement should explain thoroughly, precisely and clearly to what extent the website or app meets the requirements. For the structure, it points to the model accessibility statement in the annex of Commission Implementing Decision (EU) 2018/1523, which applies across the EU. The mandatory first section of that model covers the compliance status (fully, partially or not compliant), the content that isn’t accessible, how the statement was prepared, and feedback and contact details. The optional second section, which includes things like planned improvements, should be filled in where possible.

Format, placement and keeping it current

The statement must itself be accessible and machine-readable. It has to be reachable from the home page and from every other page, which in practice means a footer link. For apps, it goes where the app can be downloaded, or on the body’s website.

Before writing the statement, the body must actually evaluate the site. The statement says whether that evaluation was done in-house or by a third party, and it may link to the evaluation report. It has to be updated at least once a year and whenever the website or app changes substantially.

Two more German specifics tend to get overlooked. Federal bodies must respond to messages received via the feedback mechanism within one month at the latest. And section 4 of the BITV 2.0 requires explanations on the website in German Sign Language and in Leichte Sprache, a highly regulated form of easy-to-read German. These must also cover the key points of the accessibility statement. Our article on easy-to-read and plain language explains the difference between the two.

Germany’s federal monitoring body for IT accessibility (BFIT-Bund) publishes a model statement in German. It’s a good starting point, but it doesn’t replace the actual work: a template without real test results is just an empty shell.

Accessibility information under the EAA and the BFSG

For businesses covered by the BFSG, there’s no official template in the style of the public sector model. The minimum content is set out in Annex 3 of the act. In addition to the general consumer information required by German civil law, it should include, where applicable:

• a general description of the service in an accessible format
• explanations needed to understand how the service is carried out
• a description of how the service meets the relevant accessibility requirements
• the competent market surveillance authority

You publish this information in your terms and conditions or in another clearly visible way. It must itself be accessible and remain available for as long as you offer the service. In Germany, the competent authority for services is the joint market surveillance body of the federal states for accessibility (Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen, MLBF) in Magdeburg. Take its current contact details from an official source. If you operate in other EU countries, check which authority is responsible there.

Annex 3 doesn’t explicitly require a feedback mechanism or a reference to conciliation. Include both anyway. A clear way to report barriers means you hear about problems early, before someone takes them to the authority. And under the BFSG, consumers can request conciliation regardless.

The differences at a glance

• Who: the accessibility statement is for public sector bodies; the service information is for providers covered by the EAA and its national laws, such as the BFSG.
• Legal basis: Web Accessibility Directive (in Germany: BGG, BITV 2.0 and state law) versus European Accessibility Act (in Germany: BFSG with Annex 3).
• Focus: public bodies disclose what is not accessible and why; businesses mainly describe how their service meets the requirements.
• Feedback and conciliation: explicitly required for public bodies; strongly recommended for businesses.
• Authority: under the BFSG, you must name the competent market surveillance authority.
• Updates: public bodies update at least annually and after substantial changes; businesses should update whenever the service changes in a relevant way, because the information has to be accurate.

How to structure the page

Whatever the legal basis, a clear structure with descriptive headings works best. For a business covered by the BFSG, it could look like this:

1. Scope: which website, apps and service does the information cover?
2. Description of the service: what can customers do here, and how does it work, from product search to order confirmation?
3. How the requirements are met: which benchmark did you use (for example WCAG 2.1 AA or EN 301 549), and what has been implemented?
4. Known limitations: where are there still barriers, and what alternatives exist?
5. Testing and status: how and when was the service tested, and when was this information last updated?
6. Contact: how can people report barriers, and how quickly will they hear back?
7. Market surveillance authority: name and contact details of the competent authority.

Public sector bodies follow the order of the model statement and add the conciliation details and, in Germany, the explanations in sign language and Leichte Sprache.

Before and after

Here’s how much more useful concrete information can be. This is what you see on a lot of sites:

We are committed to making our website accessible. Unfortunately, this is not yet possible in all areas. If you have any questions, please contact info@example.com.

And here’s a version that actually helps:

Our shop was tested against WCAG 2.1 Level AA by an external auditor in September 2026. Product search, basket, account creation and checkout work with a keyboard and a screen reader. Our 3D sofa configurator is not yet accessible: it can’t be operated with a keyboard. As an alternative, you can choose all fabrics and sizes using the form on each product page. To report a barrier, use our contact form or call us; we reply within five working days.

The second version describes what works, names a specific limitation, offers an alternative and makes a reliable promise. That’s exactly what people need when they want to know in advance whether they can complete a purchase on their own.

The page itself must be accessible

It sounds obvious, but it’s often missed: a statement published as a scanned PDF or as an unstructured wall of text defeats its own purpose. At a minimum, check these points:

• Real headings and lists rather than bold lines, so screen reader users can grasp the structure (Info and Relationships).
• A clear page title such as “Accessibility – Shop name” (Page Titled).
• Descriptive link text, like “Report an accessibility barrier” instead of “click here” (Link Purpose (In Context)).
• More than one way to reach the page, for example via the footer and the sitemap (Multiple Ways).
• The contact option for barriers appears in the same place on every page (Consistent Help, new in WCAG 2.2).
• Plain language instead of legalese, with terms like “WCAG” briefly explained (Reading Level).

Common mistakes

Platitudes instead of facts. “We are committed to accessibility” tells nobody anything. Describe what was tested, what works and what doesn’t.

Claiming compliance without testing. A statement promising “full accessibility” when nobody has ever tested the site is risky. It sets false expectations and is easy to disprove. Always base your statement on a real evaluation; our article on accessibility testing shows you how.

Pointing to an overlay. Saying the site is accessible “thanks to our accessibility tool” proves nothing. Overlays can’t reliably fix structural problems in your code.

Outdated information. A test date from three years ago and references to sections that no longer exist destroy trust. Decide who owns the page and when it gets reviewed.

A contact option that goes nowhere. A form protected by a puzzle CAPTCHA, or an inbox nobody reads, is not a working feedback mechanism. Try the route yourself and make sure reports reach someone who can act on them.

Missing mandatory details. Public sector statements often lack the link to the conciliation body; business pages often forget to name the market surveillance authority.

Generator text left as is. Templates help, but text copied over with leftover placeholders or details that don’t match your service looks careless.

Quick checklist

• Correct legal basis identified: public sector or EAA/BFSG?
• Information based on an actual evaluation, with date and method
• Known barriers named specifically, alternatives described
• Working, accessible contact option provided
• Conciliation body (public sector) or market surveillance authority (EAA/BFSG) named
• Page reachable from every page and accessible itself
• Owner and update schedule defined

Conclusion

A good accessibility statement isn’t a legal formality you file away and forget. It’s an honest status report: what works, what doesn’t yet, and how people can still get what they need. Public sector bodies follow the Web Accessibility Directive and its national implementations, including the EU model statement. Businesses covered by the EAA – in Germany, the BFSG – describe how their service meets the requirements and name the market surveillance authority.

Either way, specific, current and verifiable information builds trust. And a contact option that really works is often the fastest route to hearing about barriers and fixing them. If you want to dig into the criteria behind the requirements, explore the WCAG guide.

Sources

• Commission Implementing Decision (EU) 2018/1523 (model accessibility statement) – EUR-Lex (opens in a new tab)
• Directive (EU) 2019/882 (European Accessibility Act) – EUR-Lex (opens in a new tab)
• Section 12b of Germany’s Disability Equality Act (BGG) – gesetze-im-internet.de (German) (opens in a new tab)
• Annex 3 of the BFSG – gesetze-im-internet.de (German) (opens in a new tab)
• BFIT-Bund, Germany’s federal monitoring body for IT accessibility (opens in a new tab)