Write an accessibility statement that matches what was actually reviewed

Anchor the statement to one dated review

Before writing a word, locate the review the statement will rest on: the notes, worksheet or report produced when someone actually examined the site. Record what it covers, who did it, and when it finished. If your accessibility work is a checkout observation pass on three templates, the statement describes that pass. If no review exists yet, the honest statement says what you are doing and how to reach you, not what you have established.

A statement assembled from intentions, a theme vendor's marketing, or a plugin's feature list misdescribes the business even if every sentence sounds modest. The reviewer and the statement author should be able to point to the same underlying record. When they cannot, the gap belongs to the statement, not to the reader's imagination.

Name the scope and method before naming any standard

Write down which pages, templates and journeys were examined: homepage, a product page, the cart, the checkout, or whatever the review actually touched. Then record the methods used, such as keyboard-only operation, text resizing, a screen-reader pass, or an automated scan. Each method reveals different things, and the statement should not imply a technique that was never used.

Name a standard and version only if the review assessed the content against it. W3C's statements guidance treats the assessment context as part of the statement itself, because a claim detached from its method and date tells a visitor nothing they can rely on. A weekend observation pass does not become a conformance claim by citing a standard's name, and a partial review does not support a site-wide conformance level. Where the review stopped short of a level, say what was done instead.

Write the limitations you already know about

A review may produce findings that are not yet fixed: a focus indicator that disappears on one template, a PDF policy that has not been retagged, a third-party payment frame whose internals you cannot change. Where the dated review record documents unresolved barriers, W3C's guidance treats known limitations as a normal part of a statement, so listing them is not an admission that defeats the purpose; omitting documented limitations is what makes the statement inaccurate. If the review found no unresolved barriers within its scope, the statement lists none — and that absence is still not a conformance claim.

Word each documented limitation the way it was recorded, and pair it with the interim route where one exists, such as an alternative way to get policy text or complete an order. Never invent limitations to fill the section, and never smooth a recorded limitation into vague reassurance; a limitation you cannot yet explain stays in the internal record with an owner.

Publish a feedback route that someone actually monitors

A statement without a working feedback route fails its most practical purpose. Choose a channel the business already reads, name the person or team responsible for answers, and describe in plain terms what a reporter can expect: their message will be read and routed, not that a fix is guaranteed. Test the route after publication the way you would test any other customer-facing path.

When an accessibility report arrives, treat it like any other evidence: record the page, the barrier described, and the date, then connect it to the next review. A report about a component you never examined is new information, not a contradiction of your statement, provided the statement stayed inside its documented scope.

Decide what happens when claims outrun the record

Give the statement an owner with authority to hold or narrow it. If the draft claims more than the dated review supports, the owner reduces the claim to the documented scope or commissions further work; the choice is not to publish first and reconcile later. Set a date to recheck the statement, because a description of a review grows stale as templates, plugins and checkout components change underneath it.

If you want a scoped Prism website-review consultation to include how the storefront presents accessibility and feedback information, provide the public URLs and the review record you hold, and confirm scope, responsibilities, fees and terms before work begins. The consultation is informational; it does not certify conformance, and which accessibility law applies to your store remains a question for qualified counsel.

Statement-scope worksheet

Complete one worksheet per draft statement. Every public claim should trace to the dated review record; anything that cannot is narrowed, held or removed before publication. Completing this worksheet does not establish conformance or legal compliance.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.