An accessibility statement explains how accessible the service is, where it has known limitations, how people can report a problem and how the statement was prepared. It is an accountability document, not a substitute for making the service accessible. Keep it accurate, easy to find and reviewed whenever the service or its testing changes.

Choose the statement source

In the service’s Accessibility Statement settings, choose the source that matches your organisation’s arrangement:

If you use a custom or external statement, verify the final public route in User view. A saved setting is not proof that people can find or use it.

Write the essential content

A useful statement has a clear headline status, a last-updated date, an explanation of the service’s accessibility, feedback contact details, and information about assessment or testing. Where there are known issues, explain what they are, who they affect, the workaround if any, and the intended fix or review point.

Do not claim full compliance unless it is supported by current evidence. Do not copy wording from another service without confirming that every assertion, contact route and date applies here.

flowchart LR
    A["Test the service"] --> B["Record findings and evidence"]
    B --> C["Update the statement"]
    C --> D["Publish and check the public link"]
    D --> E["Review after changes or new findings"]
    E --> A

Describe limitations plainly

Use the non-compliance, disproportionate-burden and out-of-scope sections only where they are accurate and applicable. Each issue should state:

• what part of the service is affected
• what someone may find difficult or impossible to do
• any available alternative or support route
• what is being done, or why a change is not currently planned
• the date it was identified and the next review date where relevant

Avoid vague statements such as “some users may experience issues”. They do not help people decide whether they can complete the service or tell the team what to fix.

Provide a real feedback route

The feedback and contact information should tell people how to report an accessibility problem and how the team will respond. Use contact details that are monitored and make sure they work without requiring someone to complete the inaccessible part of the service. Test the route periodically.

Do not rely on a generic mailbox with no ownership. The service owner should know who handles reports, what response time is expected and how confirmed issues enter the improvement process.

Record how the statement was prepared

The preparation section should state when the service was last tested, the approach used and who carried it out. Use a proportionate mix of automated checks, keyboard testing, zoom and reflow checks, screen-reader testing, manual review and, where possible, testing with people who have access needs. Automated checks are useful but cannot establish that a whole journey is accessible.

Keep the supporting evidence outside the public statement if it includes sensitive operational detail, but retain enough information for the team to substantiate the published claims.

Maintain the statement

Review the statement whenever you change common components, styles, authentication, navigation, forms, downloadable documents or an external integration that affects the journey. Also review after a reported issue, a new assessment or a material change to the audience or language support.

Related guides

• Design accessible services
• Service content, branding and languages
• Use Markdown and HTML
• Test, deploy and maintain a service