Accessibility statement: document honestly

What is an accessibility statement?

The statement is a public page on which a provider describes the state of its website or app. It says which standard is targeted, how far it is met, what is not yet accessible and how people can report barriers.

For public bodies it is required by law. For private websites without a corresponding obligation it is voluntary. The W3C still recommends it: it shows that you take the topic seriously and gives people a way to report problems. A good statement is short, specific and dated. It is written for people who have just run into a barrier.

Who has to publish an accessibility statement?

Under § 12b of the Behindertengleichstellungsgesetz (BGG, the German Disability Equality Act), federal public bodies must publish a statement for their websites and mobile applications. For federal states and municipalities, the respective state rules apply. So when working for municipalities or state authorities, check the relevant state law before you adopt a federal template. If you are unsure whether your service counts as public or private, for example in the case of a municipal company, clarify this before drafting.

Businesses within the scope of the BFSG do not have to publish a statement of this kind within the meaning of the BGG. They must, however, provide information under § 14 and Annex 3 BFSG. That is a different obligation with different content.

What must the statement contain?

For federal bodies, § 12b BGG sets out the minimum content: the parts that are not fully accessible, the reasons for this and, where applicable, accessible alternatives. On top of this come a directly accessible, barrier-free way of making contact electronically and a reference to the conciliation procedure with a link to the conciliation body.

For every statement, the W3C recommends at least a commitment to accessibility, the standard applied, such as WCAG 2.2, and contact details. Known limitations, measures taken, technical requirements, test environments and references to applicable laws are also useful. Write in short paragraphs and briefly explain technical terms such as WCAG.

How do a statement and BFSG information differ?

The information under Annex 3 BFSG describes the service and how it is carried out, explains how it meets the accessibility requirements and names the competent market surveillance authority. It belongs in your terms and conditions or in another clearly perceivable place, for example behind an ‘Accessibility’ link in the footer.

The Bundesfachstelle Barrierefreiheit (Federal Accessibility Centre) stresses the difference: anyone covered by the BFSG is in principle obliged to achieve full accessibility. Listing remaining barriers, as in a public-sector statement, is no justification there. An online shop therefore does not need a list of shortcomings as a safeguard, but barriers that get fixed. Classify your service first and check the draft against the obligations that actually apply.

How do you go about creating one?

First collect the information in a shared document with your editorial, development and customer service teams. That way you quickly see where evidence is missing before you start writing.

1. 1Name the service and its scope, such as the domain, subdomains and apps.
2. 2State the standard and level you measure against, such as WCAG 2.2 level AA.
3. 3Record the test date, the method and the pages or journeys reviewed.
4. 4Describe known barriers specifically and clearly, with alternatives where available.
5. 5Name the environments tested, such as browsers and screen readers.
6. 6Give a contact people can reach for feedback and support requests.
7. 7Decide who handles incoming reports and within what time frame.
8. 8Define a trigger for retesting, such as a major relaunch.

How do you describe the status honestly?

‘We want to remove barriers’ describes a goal. ‘The ordering process was tested on the date stated’ describes a concrete measure. Word the status based on your actual evidence and do not copy a blanket conformance claim from a template. So do not write ‘This website is fully accessible’ if you have only run an automated scan. Instead, state what you tested and how: ‘Automated scan of the home page and manual keyboard test of the contact form in November 2026.’

Describe known barriers so that the people affected understand them: ‘The filters on the product overview cannot be operated by keyboard. Until this is fixed, please use the search.’ That helps more than a reference to a criterion number. For planned fixes, give a realistic target, such as ‘with the next theme update’, and stick to it.

Where do you publish the statement and how often do you update it?

For federal bodies, § 7 BITV 2.0 (the German federal regulation on accessible information technology) specifies that the statement must be published in an accessible and machine-readable format, be reachable from the home page and from every page, and be updated annually and with every significant change. Federal bodies must respond to feedback within one month at the latest.

For private websites, a link in the footer of every page is good practice. The statement itself should be accessible, so an HTML page rather than a scanned PDF. Test the feedback channel yourself regularly. Answer reports promptly and use them as a checklist for the next revision. A statement documents the current state; the technical fix for a problem happens in the affected service.

Can a generator write the statement for you?

The W3C offers a free generator, and the Accessonaut assistant links your information to a dated scan record and saves versions in the project account. A public link and an embed only show the version you have explicitly approved; newer drafts stay private. Both tools produce a draft, not a conformance assessment. Read every sentence and delete anything you cannot back up. You are responsible for the claims, and you should have an expert clarify which obligations apply to your service. This article offers orientation and is not legal advice.