An accessibility statement is a public-facing document that explains your organization’s approach to digital accessibility. It tells users what you are doing to make your website, app, or digital service accessible, where limitations may still exist, and how people can contact you if they encounter a barrier.
For compliance, privacy, and digital teams, this document is more than a formality. It helps demonstrate intent, creates a clear feedback channel, and supports a more transparent accessibility program. Just as importantly, it gives users practical information when they need help.
In this guide, we’ll cover what an accessibility statement is, what to include, common mistakes to avoid, and a simple template you can adapt for your organization.
An accessibility statement is a webpage or published notice that describes the accessibility of a digital product or service. It usually covers:
It is not the same as an internal audit, legal memo, or technical conformance report. Instead, it is a practical communication tool written for real users, including people with disabilities, procurement teams, legal reviewers, and internal stakeholders.
A well-written accessibility statement can support both user experience and compliance readiness.
No digital experience is perfect all the time. An accessibility statement lets you communicate your efforts honestly and clearly without overpromising.
If someone encounters an accessibility barrier, they should not have to guess where to report it. Your statement should provide a direct and usable path for support.
An accessibility statement works best when it reflects an active accessibility process that includes auditing, remediation, monitoring, and updates over time. For teams building a more proactive program, continuous oversight matters just as much as the published statement itself. You can see how automation is changing that workflow in AI Agents Are Here: How Autonomous AI Will Quietly Take Over Your Accessibility To-Do List.
The strongest statements are clear, specific, and easy to understand. While the exact wording may vary by organization, most accessibility statements should include the following elements.
Start with a short statement that explains your organization’s commitment to making its digital experiences accessible to as many people as possible.
Keep the language straightforward. Avoid broad claims you cannot support.
Clarify what the statement applies to. For example, it may cover your main website, a customer portal, a mobile app, or a defined set of digital services.
If the statement only applies to certain domains, subdomains, or products, say so clearly.
Many organizations reference WCAG as the standard guiding their accessibility work. If your team is aligning with a specific version or level, include that information only if you can support it.
If you are still improving accessibility and are not ready to make a formal conformance statement, you can still explain that you are actively auditing, testing, and improving the experience.
Briefly describe the steps your organization is taking to improve accessibility. This may include accessibility audits, monitoring, remediation, design reviews, content improvements, or user feedback processes.
The goal is to show that accessibility is an active effort, not a one-time task.
If there are areas of the site or service that may not yet be fully accessible, it is often better to acknowledge them clearly than to ignore them. Be factual and concise.
For example, you might note that some older documents, legacy pages, or third-party content may present accessibility challenges while improvements are underway.
This is one of the most important parts of the statement. Provide a clear method for users to:
Use a monitored email address, contact form, or support channel. Make sure the route you provide is actually maintained.
Adding a date helps show that the statement is current and maintained. If your accessibility program evolves, your statement should evolve with it.
Your statement should be easy to read and understand. Avoid overly legal or technical language unless it is necessary. This page is meant to help users, not overwhelm them.
Do not copy generic wording that suggests full compliance if your team has not validated it. The statement should reflect your actual processes, current status, and support channels.
Accessibility statements often sit at the intersection of compliance, legal, digital, design, and support. Before publishing, confirm that the content aligns with your internal owners and workflows.
Your accessibility statement should be easy to locate, typically through a footer link, help center, legal hub, or accessibility menu. If users need it, they should not have to search for it.
Organizations that centralize legal and compliance content often find it easier to keep documents current and discoverable. That same principle is discussed in Inside the 4-in-1 Widget: Accessibility, Consent, Legal and Company Info in One Script.
An outdated accessibility statement can create confusion. Review it whenever you make meaningful changes to your site, accessibility tooling, support process, or compliance posture.
Below is a simple template you can customize. Edit the wording to reflect your organization, digital properties, and actual accessibility practices.
[Organization name] is committed to making its digital experiences accessible to all users, including people with disabilities.
This accessibility statement applies to [website, app, platform, or specific digital service].
We are working to improve the accessibility and usability of our digital properties and to support access for a wide range of users. Our efforts include [for example: accessibility testing, ongoing monitoring, issue remediation, design review, content updates, or user feedback review].
We aim to align our accessibility efforts with [insert standard or guideline if appropriate].
While we work to improve accessibility across our digital properties, some areas may not yet provide a fully accessible experience. This may include [for example: certain legacy content, third-party integrations, or older documents]. We are continuing to review and improve these areas.
If you experience difficulty accessing any part of [website/app/service], or if you need assistance or an alternative format, please contact us:
When contacting us, please include details about the page or feature you were trying to access and the nature of the issue. This helps us investigate and respond more effectively.
Last reviewed: [month day, year]
Avoid language that implies full accessibility or legal compliance unless you have the evidence to support it. Overstated claims can create risk and undermine trust.
Statements like “we care about accessibility” are not enough on their own. Users need practical details, including scope and contact options.
If there is no clear way to report an issue, the statement loses much of its value.
Accessibility is ongoing. Your statement should reflect that reality.
An accessibility statement is only one part of a mature digital compliance approach. It works best when supported by real operational processes such as accessibility audits, monitoring, remediation, documentation, and reporting.
For many organizations, accessibility also overlaps with privacy and legal transparency requirements. Teams often benefit from managing these obligations in a coordinated way rather than as separate projects. For example, if your organization is also reviewing consent practices, this guide on How to Run a Cookie Audit on Your Website in 5 Steps is a useful companion resource.
A strong accessibility statement is clear, honest, and useful. It tells users what your organization is doing, where support is available, and how accessibility concerns can be raised. Most importantly, it reflects an ongoing commitment rather than a one-time publishing task.
If your team is building or improving its accessibility program, treat the statement as a living document. Keep it aligned with your actual practices, update it as your digital properties evolve, and make sure users can find it when they need it.
No. An accessibility statement is a public-facing summary for users. A VPAT or ACR is a more formal document used in procurement and conformance contexts. They serve different purposes.
Requirements vary by organization, market, and risk profile, but many businesses benefit from having one. It improves transparency, gives users a support path, and supports a more mature accessibility process.
You can start with a template, but it should always be customized to reflect your actual website, processes, and support channels. Generic language should not replace accurate information.
Review it regularly and update it whenever there are meaningful changes to your accessibility efforts, covered digital properties, or contact methods.
Mobile apps may surface accessibility labels, but websites usually do not. That means buyers rely on other signals to assess accessibility risk. Here’s what they typically review and how teams can prepare.
App store accessibility labels can help users make informed choices, but they also create risk when teams overstate what an app actually supports. Here’s why careful, evidence-based accessibility claims matter more than checking every box.
Apple’s accessibility nutrition labels put accessibility information closer to the point of download. Here’s why that matters, what teams should review now, and how to prepare your product for greater accessibility scrutiny.
Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.
TR
