Accessibility Statements: What to Publish, What Not to Promise
An accessibility statement signals good faith to regulators, customers, and plaintiffs' firms alike. Publish your standard, your known limitations, a contact path, and a review date. Never claim full compliance you have not tested, and never let the statement go stale while the site changes under it.
Why the statement matters more than most pages
An accessibility statement is one of the few pages a demand letter will quote. Plaintiffs' firms read it before they file: a statement that claims WCAG 2.2 AA conformance on a site with obvious barriers becomes exhibit A. A statement that is honest about ongoing work, with a contact email and a recent review date, does the opposite. It signals good faith, which is the single most useful thing a statement can do.
The statement also serves real users. Shoppers with disabilities check it to learn whether the site will work for them and who to contact when it does not. A statement that names the standard you aim for and admits where you fall short is genuinely useful to them. A statement copied from a template generator is not, and disabled users can tell the difference in one paragraph.
What belongs in it
Four things. First, the standard you target, named precisely: WCAG 2.2 Level AA is the current benchmark most legal frameworks reference. Name the version and level, not just the acronym. Second, your known limitations, described honestly: third-party widgets you cannot fully control, legacy templates mid-migration, the checkout flow you are rebuilding. Specificity is credibility; vagueness reads as evasion.
Third, a contact path for accessibility issues. A real email address, monitored by someone who can act, not a generic contact form that routes to marketing. Include what you will do with reports: acknowledge within a set timeframe, investigate, and fix or provide an alternative. Fourth, a review date and an update cadence. A statement dated two years ago tells every reader the program is dead, whatever it claims.
What to never claim
Never claim full conformance you have not tested for. "Fully WCAG 2.2 AA compliant" is a testable statement, and automated scans alone do not prove it. Automated tools catch roughly a third of WCAG failures; the rest need manual testing. If your testing was scan-only, say so, or say nothing about conformance at all. An honest statement about ongoing remediation beats a false claim of compliance every time.
Never promise what the statement cannot deliver. "Accessible to all users" is untestable and therefore a liability. "Committed to accessibility" is fine as a value statement as long as the rest of the page shows the work behind it. And never publish a statement and forget it. A site that has been replatformed, rethemed, or rebuilt since the statement's date has a statement that describes a different website. That is worse than no statement.
Keeping it honest over time
Build the statement into your release process. Every major release should trigger a statement review: does the limitations section still describe the current site, does the contact path still work, is the review date current. Treat the statement like a living document with an owner, not a page that was published once to satisfy a checklist.
Link it where it belongs: the footer, the checkout, and anywhere you publish legal policies. A statement nobody can find is a statement that does no work. And when you fix a listed limitation, update the statement the same week. The statement is the public record of your program's honesty. Keep the record current, and it becomes an asset instead of a risk.