Blog
How to write an accessibility statement
2026-07-15
Published July 2026.
An accessibility statement is the one accessibility document almost every agency ends up needing to write, usually for the first time, usually under deadline pressure. Here's the shape a good one actually takes — and the mistakes that turn a good-faith statement into a liability.
What it's for
A short, published page that tells visitors and regulators: what standard you're targeting, what you've actually done, what you know is still broken, and how to report a problem. It's not a certificate and it's not a legal defense on its own — but a well-written, honest statement is evidence of a good-faith effort, and a missing one is itself sometimes the compliance gap (several jurisdictions, including under EAA-aligned rules, expect one to exist).
The five sections that matter
- Conformance target. State the standard plainly — "WCAG 2.2 Level AA" — not vague language like "accessible design principles."
- What you've done. Concrete, specific items: semantic landmarks, keyboard operability, focus indicators, color contrast level, form labeling, table structure. Generic claims ("we care about accessibility") are worse than no statement at all — they read as filler to anyone checking.
- Known limitations. This is the section agencies are most tempted to skip, and the one that matters most. Listing what you know is still broken isn't an admission of failure; it's the difference between a statement that reads as honest and one that reads as marketing. A statement with zero known limitations is not credible to anyone who actually reads it.
- How to report a problem. A real contact — email or form — and a commitment to actually respond. Silence here undermines everything above it.
- Last reviewed date. A statement without a date looks abandoned the moment anyone checks. Update it whenever you meaningfully change the site, not just on a fixed yearly schedule.
The mistake that turns a statement into a liability
Never write "this site is compliant" or "this site meets WCAG 2.2 AA" as a flat claim, even if a scan came back clean. Automated scanning — including Gangway's — reliably catches something like 30–40% of WCAG success criteria; the rest need a human pass your scan didn't do. "We are targeting WCAG 2.2 AA and here's our progress" is defensible. "We are compliant" is a claim you may not be able to back up, and it's the exact overclaim the FTC penalized accessiBe for in 2023. Say what you did. Don't certify what you didn't verify.
Where the data actually comes from
Writing this by hand means manually tallying what you fixed, what's still open, and what you never got to — easy to get wrong or let drift out of date. Gangway generates an accessibility statement draft directly from a site's live finding status: what's verified fixed becomes "done," what's open becomes a stated known limitation, nothing is assumed passing that wasn't actually checked. It's still a draft you should read before publishing under your name — but the mechanical assembly and the risk of quietly overclaiming are both handled by pulling from real scan data instead of memory.