# Accessibility Statement Example: What to Include Before You Publish

Traditional Chinese version: [https://accesserty.com/ai/guides/accessibility-statement-example-before-you-publish.md](https://accesserty.com/ai/guides/accessibility-statement-example-before-you-publish.md)

Page version: [https://accesserty.com/en/guides/accessibility-statement-example-before-you-publish/](https://accesserty.com/en/guides/accessibility-statement-example-before-you-publish/)

Last updated: 2026-10-03

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 can surface recorded statement links that match a website’s URL scope. A displayed link is not a review of the statement’s completeness or the site’s conformance.

## 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.

## Fictional example: a library site not yet fully assessed

“Clearbrook Library” is entirely fictional. This illustrates wording, not Accesserty’s statement, test results or a ready-to-publish guarantee. Use its checks, limitations and alternatives only if they are true for your service.

“We want everyone to find materials and use library services. This statement covers the Clearbrook Library homepage, catalogue search and contact page. The external lending system was not included in this assessment; its status cannot be inferred from this statement.”

“WCAG 2.2 AA is our improvement target. We have not completed a full conformance assessment. We have checked keyboard search and form error messages on the pages above; screen-reader verification is not complete. The target is not a claim of conformance.”

“Known limitation: some older publication PDFs lack tag structures, so their reading order may be unclear. To request a plain-text version, use the email contact listed on our contact page. Include this alternative in a real statement only if your team can provide it.”

“When reporting a problem, include the page address, what you wanted to do and the barrier encountered. Do not include passwords or identity documents. If the form does not work, use the email address listed on the same page. The website maintenance contact will review the report and explain the next step.”

## Replace these fields with your own evidence before publishing

The short example does not choose your conformance status, test versions or response deadline. Fill these fields from actual evidence; describe unfinished work as unfinished. This guide does not replace a statement format required in your jurisdiction.

- Service and scope: \[site name and URL\], \[covered pages and tasks\], \[unassessed scope\]. Not assessed does not automatically transfer responsibility to a third party.
- Evidence: \[check date\], \[page or version\], \[method\], \[browser, OS and assistive technology versions\]. An accessibility tree or simulation is not evidence of actual speech output.
- Limits and alternatives: \[what users encounter\], \[how to complete the same task\], \[responsible contact\]. Confirm that the alternative works.
- Contact and follow-up: \[form or email\], \[another available channel\], \[a response arrangement the team can meet\]. Do not copy a nonexistent mailbox or an arbitrary deadline.
- Maintenance: \[last updated\], \[responsible person or team\], \[next review trigger\]. Check that the statement remains true after site changes.

## 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 Signal surfaces statement links

Signal matches a website URL against the host and path scopes of recorded statements and can show the corresponding link. This is not a live search of the page or a review of the statement’s completeness or quality. Publishing a clear statement does not guarantee a Signal badge; no badge does not mean no statement exists. Open the original link to check scope, date, limitations and contact options. The badge is not site certification or a whole-site conformance guarantee.

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

- [Start a draft with the W3C WAI statement generator](<https://www.w3.org/WAI/planning/statements/generator/>) — Gather the scope you actually checked and known limitations before using the generator. Review the draft; it does not replace website testing.

- [Help readers find the statement and contact details](<https://accesserty.com/en/guides/why-accessibility-statements-should-be-easy-to-find/>)

- [Accessibility statement glossary page](<https://accesserty.com/en/glossary/accessibility-statement/>)

- [Accesserty Signal](<https://accesserty.com/en/signal/>) — Show public accessibility signals in search results and let users report barriers.

- [How to read an accessibility statement](<https://accesserty.com/en/guides/how-to-read-accessibility-statements/>)

- [W3C WAI: Developing an Accessibility Statement](<https://www.w3.org/WAI/planning/statements/>)

- [Website data handling](<https://accesserty.com/en/data-handling/>) — Understand what Pulse and Signal collect, what they do not collect, and how public signals differ from private data.

- [Accessibility practice and maintenance guides](<https://accesserty.com/en/guides/>) — Browse guides by practical task: public signals, pre-release checks, post-launch maintenance, and standards limits.