Writing an Accessibility Statement That Stays Current
An accessibility statement is only useful if it tracks the live store. How to write one, date it, and keep it honest as templates and apps change.
An accessibility statement tells shoppers what standard you aim for, what you know does not work yet, and how to get help. A statement copied at launch and never updated does the opposite of its job: it promises a store that may no longer exist and hides the contact route shoppers actually need.
This guide covers what a credible statement contains, how to keep known issues honest without turning the page into a legal document, and the review triggers that keep it current.
Start with standard, scope, and date
Name the standard you target, usually WCAG 2.2 AA, the parts of the site it covers, and the date the statement was last reviewed. Scope matters because third party content, older documents, and user uploaded material often follow different rules, and shoppers deserve to know which is which.
Add how conformance was assessed: self evaluation, external audit, or both, and when. A statement that says how it knows what it claims is more believable than one that simply asserts full compliance in a single line.
List known issues in shopper language
Known issues should describe the barrier and the workaround, not a rule code. Payment widget focus order is being fixed, here is how to complete checkout by keyboard in the meantime, tells a shopper something useful. A list of criterion numbers tells them nothing they can act on.
Keep the list short and dated. If an issue is fixed, remove it and note the fix in your internal log. A statement that still lists barriers fixed a year ago signals that nobody owns the page, which undermines everything else on it.
Make the contact route real and usable
Offer at least two ways to report a barrier, and make sure both work for the people who need them. A phone only route excludes some shoppers, and a form that is itself inaccessible makes the point badly. State a response time you can actually meet and keep to it.
Route reports into the same queue as other accessibility findings, with an owner. A report that lands in a general inbox with no triage disappears, and the shopper who sent it will reasonably conclude the statement was decorative.
Set review triggers, not just a review date
Review the statement after a theme change, a new checkout extension, a major app install, and at least every quarter. Each review checks three things: does the known issues list match current monitoring, does the contact route still work, and does the claimed standard still match your test method.
Assign a named owner. Statements go stale because they belong to everyone in general and nobody in particular. One owner with a calendar trigger keeps the page as current as the store it describes.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Making Loyalty and Rewards Programs Accessible End to End, Writing a VPAT That Enterprise Buyers Actually Trust, and Auditing a Headless Shopify Storefront for Accessibility.
Frequently asked questions
What should an accessibility statement include?
The standard targeted, the scope covered, how conformance was assessed and when, known issues in plain language with workarounds, and a working contact route for reporting barriers, plus the date of the last review.
Should a statement claim full compliance?
Only if current testing supports that claim across the full journey. Most stores are more credible stating partial conformance with known issues and a plan. Shoppers and buyers trust a specific, dated statement more than a blanket claim.
How do I write known issues without legal risk worries?
Describe the shopper impact and the workaround in plain terms and avoid speculating about fault. Take advice on wording if your organisation requires it, but do not let that become a reason to publish nothing. A silent statement helps no shopper today.
Who should own the statement?
A named person or role with a quarterly review trigger and extra reviews after theme, checkout, or major app changes. Ownership is what separates a living statement from a launch day page that quietly expires.