Checking Your Accessibility Statement for Accuracy
An accessibility statement that promises what the site does not deliver creates its own risk. How to audit the statement against the site as it really is.
Many stores publish an accessibility statement copied from a template: a conformance claim, a list of standards, and a contact route nobody monitors. When the statement and the site disagree, the statement becomes evidence against the store rather than protection for it.
Checking accuracy is unglamorous work. Read every claim, test it, fix the claim or fix the site, and put a date and an owner on the result.
Test every factual claim
If the statement claims a conformance level, there should be an evaluation behind it, dated and scoped to named templates and journeys. A claim covering the whole site, made after testing only the homepage, does not hold up and should be narrowed to what was actually checked.
Claims about features deserve the same treatment. If the statement says documents are available in accessible formats, order one and see what arrives and how long it takes.
The contact route must work
A statement usually offers an email or form for accessibility problems. Send a test message and measure the reply. A dead inbox or a reply that takes a month turns a good intention into a documented failure to respond.
Say in the statement what a reporter can expect: acknowledgement within a stated number of days, and an alternative way to buy or get help while a barrier is being fixed, such as assisted ordering.
Keep it current or keep it honest
Statements should name when they were last reviewed and be revisited after redesigns, platform changes, and major app additions. A statement dated three years ago describing a previous version of the site misleads everyone who reads it.
Known limitations belong in the statement, plainly listed. Admitting that a third party booking tool has faults, with the workaround offered, reads as diligence. Claiming full conformance over the same tool reads as carelessness.
Assign the statement an owner and a date
Statements drift because nobody owns them. Give the document a named owner, a review date visible on the page, and a trigger list, redesign, platform change, new checkout or returns tool, that forces an early review. Ownership does not require a specialist: it requires someone who notices when the site has changed enough that the words describing it need checking again.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Checking Vendor Accessibility Claims and VPATs, ADA Risk in Live Chat Widgets, and Keeping Evidence of Accessibility Remediation.
Frequently asked questions
Can an inaccurate accessibility statement make things worse?
Yes. Overstated claims that the site itself contradicts undermine credibility with regulators, claimants, and customers. An honest statement with known limitations and a working contact route is far stronger.
How often should a statement be reviewed?
At least yearly, and after any redesign, platform change, or major new component. The review should retest the claims, not just update the date.
What should the statement say about known barriers?
Name them plainly, say what is being done, and offer an alternative route to the same service in the meantime. Specific honesty about limits is more defensible than a general claim of full access.
Should the feedback route be tested?
Yes, by sending a real test message and timing the response. A statement inviting reports through an unmonitored inbox is itself an inaccuracy.