September 15, 2025 · reala11y team
Write an Accessibility Statement That Doesn't Overpromise
A practical, honest structure for a WordPress accessibility statement that reflects your real conformance status—no overclaiming, no legal exposure.
An accessibility statement is one of the few pages on your site where honesty is a legal feature, not just a virtue. Done well, it tells disabled users what to expect, gives a regulator a good-faith record, and gives you a place to be candid about work still in progress. Done badly—padded with claims you can’t back up—it becomes the exhibit someone screenshots later.
This is a structure you can adapt for any WordPress site, built around one rule: describe what is actually true today.
Why the wording carries weight now
The legal backdrop changed fast. WCAG 2.2 became a W3C Recommendation on 5 October 2023 (WCAG 2.1 dates to 2018). The US DOJ published its ADA Title II web rule in April 2024, and the European Accessibility Act became enforceable on 28 June 2025. Most pointedly, on 21 April 2025 the FTC entered a final order against accessiBe with a $1,000,000 penalty—largely over marketing that claimed an automated tool delivered conformance.
The lesson is narrow and useful: a statement that overclaims is worse than a modest one. Regulators and courts read these pages.
A structure that holds up
1. Conformance status—stated carefully
Skip “this site is WCAG compliant.” Conformance is a measured result, not a switch you flip. Describe your actual posture instead:
We are working toward WCAG 2.2 Level AA. This site is partially conformant: some content does not yet fully meet the standard.
“Partially conformant” is the W3C’s own term for exactly this situation. It is honest and it is defensible.
2. What you’ve done
Be specific about the work. This is where you earn credibility:
- Code-level fixes applied (e.g.
langattributes,rel="noopener", focus-visible styles, restored pinch-zoom) - Manual review of key templates and high-traffic pages
- The tooling you use, named plainly
A tool like reala11y belongs here as part of the process, not as a guarantee. It fixes code-level issues at the source rather than layering an overlay on top—see how it works. State that and stop; don’t let the tool’s name imply an outcome it can’t promise.
3. Known limitations
The section most statements omit, and the one that protects you most. List what you already know is incomplete:
- Third-party embeds (maps, video players, payment widgets)
- Older posts or PDFs not yet remediated
- Complex interactive components under review
Naming a gap is not an admission of failure—it’s evidence of an honest, ongoing process.
4. How users get help
Give a real contact method and a response commitment you can keep:
If you hit a barrier, email [email protected]. We aim to respond within five business days and will work with you to provide the information another way.
5. Assessment method and date
Say how you evaluated the site (self-assessment, third-party audit, or both) and when. Add a “last reviewed” date and keep it current—a statement dated three years ago undercuts itself.
The honest math behind the claims
Automated tooling—ours included—typically detects roughly 30–40% of WCAG issues by criteria. The rest needs human judgment: Is that alt text meaningful? Does the reading order make sense? Can you complete the form by keyboard alone? No scanner answers those.
So your statement should reflect a pairing: automated detection plus manual review. That framing is accurate, and it quietly explains why you can’t promise full conformance—which keeps you on the right side of the wording.
If you want to verify which criteria are actually in scope before you describe your status, the WCAG 2.2 guide breaks the success criteria down by level; the broader WCAG guides cover the earlier versions.
Phrases to retire
- Absolute accessibility claims — that a site is totally accessible, or usable by absolutely everyone.
- Asserting, as settled fact, that a site is “compliant” with WCAG, the ADA, or Section 508.
- Any promise of legal immunity — wording that implies a site can never be sued.
Replace them with what you can stand behind: working toward, partially conformant, we identify and fix where safe, we review the rest manually.
The honest takeaway
A good accessibility statement isn’t a trophy—it’s a logbook. It says where you are, what you’ve fixed, what’s left, and how to reach a human when something breaks. That posture serves disabled users better than any badge, and it’s the version that holds up when someone reads it closely. Write the true one. It’s also the safe one.