What should a Shopify accessibility statement promise, and what should it avoid?
An accessibility statement is evidence, not marketing. Promise the standard you meet, the parts you are still working on, and how to contact you. Avoid promises the theme cannot keep.
A statement is a record, not a badge
Most accessibility statements read like marketing copy: broad claims, no dates, no specifics. That style is worse than useless. In a dispute, a vague statement becomes an exhibit for the other side, a list of promises the store cannot prove it kept. A good statement is narrower, drier, and far more useful. It says what standard the store targets, what has actually been done, what is still in progress, and how to report a problem.
Promise a specific standard
Name the standard and the level: WCAG 2.2 Level AA. Not "accessible to all users," not "we care about accessibility," not a reference to a law without a technical target. The standard is the only promise that can be tested, and testability is what makes it meaningful. If the store is not yet at AA, say so plainly and say what the plan is. An honest statement of partial conformance beats a false claim of full conformance in every forum that matters.
Date the claim. "Evaluated against WCAG 2.2 AA in September 2026" is a statement of fact. "Committed to accessibility" is a sentiment. Facts age into history; sentiments age into liability.
Describe what was actually done
List the concrete work: the audit scope (which templates and flows were tested), the methods (automated scans plus manual keyboard and screen reader testing), and the remediation completed. This does not need to be exhaustive. Three to five sentences of specifics signal that the statement describes a real program rather than a template someone pasted.
Name the known limitations. Every store has them: a third-party review widget the theme cannot restyle, a checkout element the platform controls, a legacy PDF. Listing limitations with a plan ("we are evaluating alternatives to the review widget in Q1") shows diligence. Hiding them shows nothing, because a tester will find them in an afternoon.
Provide a real contact path
The statement must give people a way to report barriers: an email address that is monitored, a phone number, or a form. "Contact us" that leads to a general support queue with a two-week response time is not a contact path for accessibility purposes. Say who monitors it and how quickly they respond, then actually respond that quickly. The feedback channel is the part of the statement most likely to be tested, by a real user with a real problem, before any lawyer is involved.
Log every report and its resolution. The log is the quiet powerhouse of the whole program: dated evidence that the store listens and fixes. If a complaint ever escalates, the log shows a pattern of responsiveness. Without it, the statement is just words.
What to avoid
Avoid claiming full compliance with the ADA itself. The ADA does not define a technical standard for websites, so the claim is untestable and invites argument. Claim conformance to WCAG, which is testable, and let lawyers map that to the law.
Avoid promising perfection: "fully accessible," "accessible to all," "barrier-free." No nontrivial site meets that bar, and the overclaim becomes the headline of the demand letter. Promise diligence, process, and a working feedback loop instead.
Avoid copying a statement from another site verbatim. Templates are fine as starting points, but the specifics (audit dates, scope, contact, limitations) must be true of this store. A statement that describes work that never happened is worse than no statement, because it is a written misrepresentation.
Keep it current
Review the statement quarterly and after every major theme change. Update the evaluation date, the remediation list, and the known limitations. A statement dated two years ago describing a theme the store no longer uses tells its own story, and it is not a flattering one. The statement should read like a living document because it describes a living program.