Accessibility Statements That Aren't Legalese: How to Write, Publish, and Maintain Them

Every organization with a digital presence needs an accessibility statement. Increasingly, regulations require them—the European Accessibility Act mandates public accessibility statements for in-scope digital services, and the ADA's regulatory framework creates strong incentives for US organizations to document their accessibility commitments.

But beyond compliance, an accessibility statement template serves a practical purpose: it tells users with disabilities what to expect and how to get help. When written well, it builds trust. When written poorly—or when it overpromises and underdelivers—it creates liability and erodes confidence.

The problem is that most accessibility statements read like legal disclaimers written by lawyers for lawyers. Dense, defensive, and utterly useless to the users they're supposed to serve. Your ADA statement doesn't have to be that way.

This guide covers what an effective accessibility statement includes, how to write in plain language that users actually understand, and how to keep your statement current as your accessibility work evolves.

What a Good Accessibility Statement Includes

Scope and Standards

Users need to know what properties your statement covers and what standards you're working toward.

What properties and platforms are covered. Be explicit: "This statement covers our main website at example.com, our mobile apps for iOS and Android, and our customer portal at portal.example.com." If some properties aren't covered, say so. The W3C's guide to accessibility statements emphasizes clarity about scope.

Target standards and conformance level. State which version of WCAG you're targeting and at what level. "We aim to conform to WCAG 2.2 Level AA" is clear. Avoid vague statements like "we follow accessibility best practices" without specifying what those practices are.

Legal and regulatory context. If you're subject to specific regulations (ADA, Section 508, EAA, AODA), acknowledge them. This sets expectations about what you're legally required to do versus what you're doing voluntarily.

Current Status and Known Limitations

Honesty builds trust. Users and regulators respect organizations that acknowledge their accessibility work is ongoing.

Honest acknowledgment of unresolved issues. If you know your video player doesn't have reliable captions yet, say so. "We are aware that some older video content lacks captions. We are actively adding captions and expect to complete this by Q2 2025." This is infinitely more useful than pretending the issue doesn't exist.

Areas that have been tested and verified. Share what you're confident about. "Our checkout process has been tested with screen readers including JAWS, NVDA, and VoiceOver, and with keyboard-only navigation." This gives users confidence in specific journeys while being honest that other areas may have gaps.

Third-party content limitations. If you embed content you don't control (social media feeds, embedded maps, user-generated content), acknowledge that accessibility may vary. WCAG's guidance on third-party content recognizes these challenges.

Feedback and Contact Mechanisms

Users need a clear path to report problems and request accommodations.

How users can report accessibility problems. Provide a specific email address, phone number, or contact form. Don't just point to a general "contact us" page. "Email accessibility@example.com to report accessibility barriers" is actionable.

Expected response time. Set expectations: "We will respond to accessibility feedback within 3 business days." Then meet or exceed that commitment.

How users can request accommodations. Some users need assistance beyond what the digital interface provides. "If you need assistance accessing any content or completing a transaction, please contact us at..." This shows you understand that digital accessibility doesn't solve every situation.

Alternative formats available. If you can provide content in alternative formats (large print, audio, plain text), mention this. It demonstrates commitment beyond the minimum.

Tone and Language – Human, Not Legal Robot

Writing for Users, Not Just Regulators

Your accessibility statement serves two audiences: regulators who want to verify compliance, and users who want to know if they can use your services. The user audience is more important—and writing for them will satisfy regulators too.

Use plain language. Avoid jargon. Instead of "We strive to conform with Level AA of the Web Content Accessibility Guidelines version 2.2," write "We're working to meet WCAG 2.2 AA, an internationally recognized set of accessibility standards." The Plain Language Association International offers guidelines for accessible writing.

Write at an 8th-grade reading level. People visiting your accessibility statement may have cognitive disabilities, may not speak English as a first language, or may simply be tired and stressed. Simple sentences serve everyone. Tools like Hemingway Editor can help assess readability.

Avoid defensive hedging. Phrases like "we endeavor to" and "we make reasonable efforts to" read as weasel words. State what you do, what you're working on, and what limitations exist. Direct language is more trustworthy than lawyers' hedges.

Examples of Strong, Empathetic Phrasing

Instead of: "While we strive to adhere to the accepted guidelines and standards for accessibility and usability, it is not always possible to do so in all areas of the website."

Write: "We know our site isn't perfect yet. We're actively fixing accessibility issues, and we want to hear from you when you encounter barriers."

Instead of: "To the extent that any content on the Website cannot be made accessible, it will be made available in another format which is accessible."

Write: "If you can't access any content on our site, contact us and we'll provide it in a format that works for you—like email, phone call, or plain text document."

Instead of: "The company assumes no responsibility for the accessibility of third-party content."

Write: "Some content on our site comes from other companies (like social media feeds). We can't fully control their accessibility, but we're happy to help if you encounter problems."

Emphasize commitment, not perfection. No site is perfectly accessible. An honest statement that acknowledges ongoing work is more credible than one claiming everything is fine.

Operationalizing and Maintaining the Statement

Versioning and Updates

An accessibility statement is a living document. Treat it like product documentation that needs maintenance.

How often to revisit and update. At minimum, review your statement quarterly. Update it whenever you fix significant issues, discover new problems, or change your accessibility roadmap.

Version history. Consider including a "Last updated" date or version history so users can see the statement reflects current reality. "Last updated: January 2025" builds confidence that the statement isn't stale.

Link changes to roadmap milestones and releases. When your statement says "We expect to add captions to all videos by Q2 2025," track that commitment. When you complete it, update the statement. This creates accountability.

Connecting to Metrics

Your accessibility statement should reflect actual data, not aspirations.

Use data from accessibility dashboards. If you track accessibility metrics, reference them: "Our automated scans cover 95% of our public pages" or "We've resolved 340 accessibility issues in the past year."

Reflect improvements measured over time. Your statement can show progress: "Since 2023, we've reduced critical accessibility issues by 60%." This demonstrates ongoing investment, not just a one-time effort.

Be prepared to back up claims. If you state that your checkout process is accessible, be ready to share testing methodology if asked. Vague claims invite scrutiny; documented claims demonstrate rigor.

Using TestParty Data to Feed Your Statement

TestParty provides the metrics and evidence that make your accessibility statement credible and easy to maintain.

Number of pages scanned and coverage. TestParty dashboards show exactly how much of your digital presence is actively monitored. Reference this: "We continuously scan over 10,000 pages across our properties for accessibility issues."

Issues found and fixed. Track your remediation progress with concrete numbers. "In 2024, we identified and resolved 523 accessibility issues across our platforms."

Coverage trends over time. Show that your accessibility program is improving, not static. TestParty's trend reporting demonstrates sustained investment.

Roadmap items and target dates informed by data. When TestParty identifies issues, you can commit to specific fix timelines in your statement. Data-driven commitments are more credible than vague promises.

Conclusion – A Living Document, Not a One-Time Checkbox

An accessibility statement template is just a starting point. The real work is maintaining a statement that honestly reflects your current state, clearly communicates your commitments, and provides genuine help to users who need it.

The best accessibility statements share common traits:

• Clarity about what's covered and what standards apply
• Honesty about current limitations and known issues
• Actionable contact mechanisms for feedback and accommodation requests
• Human language that users can actually understand
• Current content that's regularly reviewed and updated

Your ADA statement or EAA accessibility statement isn't just a compliance checkbox. It's a public commitment to users with disabilities—a promise about how you'll treat them. Write it accordingly.

Need help turning your accessibility efforts into a clear public statement? Talk to us about a data-backed accessibility narrative built on real metrics from your accessibility program.

Related Articles:

• The True Cost of Inaccessibility and Why Metrics Matter More Than Ever
• 13 Essential WCAG Compliance Statistics Reshaping Web Accessibility Standards
• The Metrics That Matter: A Deep Dive into Digital Accessibility KPIs