Skip to main content :::
:::

Accessibility Statement Example: What to Include Before You Publish

Examples and generators can help you start, but a useful accessibility statement is not just polished text. This guide explains the scope, standards, limits, feedback path, and maintenance rhythm to check before publishing.


Summary

  • A good accessibility statement example is not a promise paragraph; it helps users understand scope, standards, limits, and feedback options.
  • The W3C WAI generator is a useful starting point, but teams still need to fill it with site-specific evidence before publishing.
  • Accesserty Signal treats clear and findable statements as public signals, not certifications or whole-site guarantees.

Start with who the statement is for

Accessibility statements are often treated as compliance documents, but they should first serve people who encounter barriers. When someone cannot submit a form, understand an error message, operate a menu, or needs an alternative path, the statement should provide a next step.

That means an example or template is only a starting point. Before publishing, check whether the text answers the questions users actually have: what the statement covers, which standard the site uses, where limits may remain, and who to contact when something fails.

What a usable statement should include

W3C WAI guidance says an accessibility statement should at least include a commitment to accessibility for people with disabilities, the accessibility standard applied, and contact information for users who encounter problems. That is the minimum base, not the full endpoint.

A more practical statement often also includes known limitations, measures the organization has taken, technical prerequisites, tested environments, and applicable national or local laws or policies. It does not need to read like an audit report, but it should be specific enough for users and maintainers to understand.

  • Website or service name: identify which website, app, service, or version the statement covers.
  • Scope: explain whether it covers the whole site, selected pages, authenticated flows, PDFs, third-party content, or mobile apps.
  • Standard and status: name WCAG 2.2, WCAG 2.1, EN 301 549, or local requirements where relevant, and say whether the content is fully conformant, partially conformant, still being improved, or not fully assessed.
  • Known limits and alternatives: describe problems in language users understand, not only by success criterion number.
  • Feedback path: provide a usable form, email, phone number, or other contact method, and say how or when people can expect follow-up.
  • Maintenance information: include update date, assessment approach, responsible team, or ongoing improvement rhythm.

When using a generator, do not let the template make the judgment

The W3C WAI Accessibility Statement Generator is a reliable drafting tool. It helps organize basic information, measures taken by the organization, technical information, feedback, and complaints process, and it generates downloadable content in the browser.

But the generator cannot know your actual website scope, which pages were reviewed, which flows still have issues, or whether third-party content is under your control. Those judgments must be filled in by maintainers, product teams, legal teams, or accessibility specialists based on the real service.

Avoid turning the statement into an overclaim

The riskiest statement is not one that sounds plain; it is one that sounds too certain. Claims such as “fully compliant with all accessibility standards” or “100% accessibility compliant” become less credible when they do not include scope, date, assessment method, and known limits.

A more honest approach is to explain which standard you refer to, what scope was reviewed, what is still being improved, and how users can contact you when they encounter barriers. That makes the statement a maintenance entry point, not a one-time brand promise.

After publishing, make it findable

A well-written statement has limited value if it is hard to find. W3C WAI recommends making accessibility statements easy to locate, with links from places such as the footer, help menu, sitemap, about page, or other prominent areas.

Link text should also be consistent and clear, such as Accessibility or Accessibility Statement. Avoid placing the only entry point inside images, PDFs, vague policy pages, or interactions that require several steps to discover.

How Accesserty treats these statements

Accesserty Signal treats discovered public accessibility statements as traceable signals. That means users can more quickly see that a website has a public explanation and feedback entry point. It does not mean Accesserty certifies the site, and it does not mean the whole site has no barriers.

For maintainers, the goal is not to write the safest or most polished paragraph. The goal is to create a public entry point that can be found, understood, and maintained over time. That matters more than whether the statement looks like a generic example.

Related pages