What an accessibility statement must contain and how to write one well.

Required content

EU and Luxembourg law require an accessibility statement to include:

• Identification of the service.
• Conformance status: full, partial, or non-compliant.
• The applicable referential and version.
• Scope of the audit (what was evaluated and what was not).
• Known accessibility limitations and exceptions.
• Date of the most recent audit.
• Date of the next planned review.
• Contact information for accessibility feedback.
• Enforcement procedure (where users can escalate complaints).

The exact phrasing of some sections is prescribed by law. Use the statement template editor to enforce this. See /docs/statement-template-editor.md.

Tone

• Factual, not defensive. "The service does not conform to criterion X.Y because Z" is correct. "We are working hard to improve accessibility" is filler.
• Specific, not generic. A list of known issues with criterion references is useful. A vague disclaimer is not.
• First-person from the service operator's perspective, not the auditor's.

Common quality problems

• Listing only the conformance percentage and skipping the issues section.
• Promising remediation timelines that are not tracked.
• Omitting the contact and enforcement sections.
• Failing to update the statement after the next audit.

Rolling forward

The statement is a living document. After each audit:

• Update the audit date and conformance status.
• Refresh the issues list.
• Set the next review date.
• Confirm contact information is still valid.

Relationship to the audit

The statement is not the audit report. The report is the technical document; the statement is the public declaration distilled from it. Many statements pull issues directly from finding text, which is why finding text quality matters. See finding quality.