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.