Skip to main content :::
:::

Why Accessibility Statements Should Be Easy to Find

The issue with accessibility statements is not only whether they exist, but whether people, search engines, and assistive tools can find them when needed. This research-oriented guide explains why statement findability is a public accessibility signal.


Summary

  • An accessibility statement is not a dataset, badge, or guarantee. It is better understood as a traceable public clue.
  • W3C WAI recommends that accessibility statements be easy to find, and the EU model accessibility statement embeds access, findability, and regular review into its public-sector model.
  • In practice, statements may be buried in footers, policy pages, PDFs, language versions, or support flows. Existing is not the same as being findable when needed.
  • Accesserty treats statements as public accessibility signals: finding one does not prove whole-site accessibility, and not finding one does not prove that no accessibility work exists.

Research question: why can a statement exist and still be hard to see?

Many discussions begin by asking whether a site has an accessibility statement. That question matters, but it is incomplete. For someone who has just encountered a barrier, the more immediate question is: can I find it now, and does it tell me what to do next?

While organizing public accessibility signals, Accesserty repeatedly sees a practical pattern: a statement may exist, but the entry point is unstable. It may live in a footer, policy page, legal page, PDF, support article, a specific language version, or only be discoverable through site search. That does not mean the site has done nothing, and it does not make the statement worthless. It does reduce the chance that the statement will be used.

This article therefore does not treat accessibility statements as a simple yes-or-no field. It treats them as public signals: what clues does a website expose, and can those clues be found by people, search engines, assistive tools, and maintainers when they are needed?

Official guidance already treats findability as part of the work

W3C WAI guidance on accessibility statements explicitly treats findability as part of statement placement. It recommends linking from multiple places, such as the footer, help menu, sitemap, about page, and other prominent areas. This is not a cosmetic recommendation; it affects whether people can find an entry point when they encounter a barrier.

The EU model accessibility statement follows a similar logic. Commission Implementing Decision (EU) 2018/1523 establishes a model accessibility statement for public sector bodies, encourages regular review and updates at least annually, and encourages statements to be easily accessible from each web page. That means the model is concerned not only with wording, but also with access and re-use.

These official sources support a conservative conclusion: an accessibility statement is not finished merely because one page exists. It should be a public entry point that people can predictably find, understand, and use to take the next step.

People need a next step, not polished promises

When someone cannot operate a control, read content, hear media, submit a form, or complete a task, they are usually not looking for a brand statement. They need to know whether there is an alternate path, whether they can report the barrier, what information would help, and whether someone will handle it.

That is why the content and entry point of a statement need to be evaluated together. A complete statement that is hard to find has limited value for users. A visible statement that only says “we care about accessibility” also fails to provide enough clues.

How visibility helps judge whether a statement is useful

Visibility is not merely an SEO technique. It is a set of signals that help users and maintainers judge whether public information is usable. These signals do not prove whole-site accessibility, but they make it clearer whether the site exposes known limits, feedback paths, and maintenance responsibility.

Language is especially important for multilingual sites. If a user encounters a barrier on an English page but can find a statement only in another language, or if a government, education, finance, or transport service exposes the statement only as a PDF, the cost of finding the next step increases.

  • Use clear link text such as “Accessibility” or “Accessibility Statement.”
  • Place it where people naturally look for help or contact information, such as the footer, help center, or contact page.
  • Keep the statement in the current page language when possible, or provide a clear cross-language path.
  • Expose the update date, scope, known limitations, and feedback path.
  • Avoid making images, PDFs, scripted interactions, or hard-to-search locations the only entry point.

Findable still does not mean fully accessible

A findable accessibility statement is a useful signal, but it is not a complete guarantee. It may cover only part of a service, a specific domain, a specific version, or a specific period. It may not reflect a recent update. Conversely, not finding a statement does not prove that no accessibility work exists.

This boundary matters. Treating a found statement as proof that a site is accessible overstates what the statement can prove. Treating a missing statement as proof that a site does not care may also misread teams whose work is not exposed through a public statement.

A more responsible framing is this: a statement is a traceable public signal. It helps users see how a website explains itself, and it helps maintainers check whether those explanations can be found. It does not replace audits, user reports, assistive technology testing, or ongoing maintenance.

Why Accesserty collects statement URLs

Accesserty Signal collects public accessibility statement URLs so people can notice traceable clues in search results or on the current page. It is not a rating system, and it does not claim that a site fully conforms to a standard.

While the collection is still incomplete, Accesserty should not package the result as a global ranking or complete dataset. The more honest value is narrower: people can find statements and feedback paths faster, and maintainers can check whether their own public accessibility information is visible enough to be found.

This also makes Accesserty different from a generic checker. DevCheck supports pre-release and in-page preliminary review. Pulse supports post-launch monitoring of reports and interaction barriers. Signal works on the visibility of public signals. None of these is the final verdict; each helps teams see what is known and what is still missing.

The conservative conclusion

If a website has published an accessibility statement, the next question should not only be whether the wording looks polished. Better questions are: can users find it from major pages, can search engines and assistive tools recognize it as accessibility information, and does it explain scope, limitations, update date, and feedback path?

These questions do not turn a statement into a certification, and they do not make a website automatically conform to WCAG. Their value is more practical: reducing the search cost after a user encounters a barrier, helping maintainers receive clues, and moving public accessibility information from mere existence toward a signal that is more likely to be used.

Related pages