How to write an accessibility statement (EAA / BFSG)

An accessibility statement is the one document every accessibility law asks you to publish. Under the European Accessibility Act (Annex V) and the German BFSG (§ 14, Anlage 3 BFSGV), service providers must explain — in an accessible format — how their service meets the accessibility requirements. Here is what to put in it and where.

What it must contain

• General description of the service in accessible formats: what the website/app does and which parts the statement covers.
• How the requirements are met: the standard you target (EN 301 549 / WCAG 2.1 AA), the methods you used to assess conformity (automated scan, manual review, external audit), and the date.
• Conformance status: fully conformant, partially conformant (list the known gaps and when you plan to fix them), or non-conformant.
• Feedback mechanism: an accessible way for users to report barriers, with a response commitment.
• Enforcement contact: the competent market-surveillance authority users can turn to (in Germany the MLBF; in other member states the national body).
• Date of the statement and of the last review.

A structure that works

1. Commitment — one paragraph on why accessibility matters to you.
2. Scope — which domains, apps and content are covered.
3. Conformance status and standard — “We aim to conform to WCAG 2.1 Level AA as referenced by EN 301 549.”
4. Assessment method — how and when you checked (e.g. “automated axe-core scan of all key journeys on {date}, plus manual keyboard and screen-reader review”).
5. Known limitations — honest list of open issues, affected users, and target dates.
6. Third-party content — what you cannot fully control (embedded maps, payment iframes) and what you are doing about it.
7. Feedback and contact — email, form, phone; response time.
8. Enforcement procedure — the authority and how to reach it.
9. Date created / last updated.

Where to publish it

• As its own page at a stable URL (e.g. /accessibility), linked from the footer of every page.
• In the same languages as the service. A German shop needs a German Barrierefreiheitserklärung (see the BFSG-Checkliste).
• In an accessible format itself — semantic headings, real text, no PDF-only version.

Common mistakes

• Claiming “fully compliant” on the strength of an automated scan alone. Automation covers only part of WCAG; say “partially conformant” and list what is open.
• Copying a template without dates, methods or contact details.
• Publishing once and never updating — review at least yearly and after major releases.
• Relying on an overlay widget as the “measure taken”. Authorities and courts look at the underlying code.

Generate a first draft

FixRamp's statement generator takes your scan result — score, standard, date, open issues — and drafts a statement with the sections above. Edit the scope, contact and known-limitations sections, then publish. Re-scan and refresh the statement after each release.

See our own accessibility statement as a live example. General information, not legal advice.