Accessibility Statement: What It Is, Why You Need One, and How to Write It
An accessibility statement is one of the most visible signals your organization sends about its commitment to digital inclusion — yet most websites still don't have one. This guide explains exactly what an accessibility statement is, why it matters legally and reputationally, and how to write one that actually holds up under scrutiny.
<p>More than 96% of the top one million websites fail to meet basic WCAG accessibility standards — and yet the number of ADA-related web lawsuits keeps climbing every year. In this environment, an accessibility statement is not just a polite gesture. It is one of the most concrete, publicly visible signals that your organization takes digital inclusion seriously, and in an increasing number of jurisdictions, it is also a legal requirement. If you do not have one yet, this guide will walk you through everything you need to know to get it right.</p>
<h2>What Is an Accessibility Statement?</h2>
<p>At its core, an accessibility statement is a public declaration of your organization's commitment to making your website — and the digital services it delivers — accessible to all users, including people with disabilities. It sits on a dedicated page of your website and tells visitors, in plain language, what standards you are targeting, what you have done to meet them, where gaps still exist, and how to reach someone if they hit a barrier.</p>
<p>It is important to distinguish an accessibility statement from related but different documents. An internal accessibility <em>policy</em> outlines your organization's internal goals and processes — who is responsible, what workflows apply, how procurement decisions are made. An accessibility statement, by contrast, is outward-facing. It is written for your users, not your team. A Voluntary Product Accessibility Template (VPAT) or Accessibility Conformance Report (ACR) is a highly technical document primarily used in enterprise procurement contexts. An accessibility statement sits between these: it should be honest and substantive, but also understandable by any member of the public who lands on the page.</p>
<p>Think of it as your accessibility promise, written in the open. It signals to users with disabilities that you see them, that you are working to serve them, and that there is a real person they can contact when things go wrong. It also demonstrates to regulators, auditors, and opposing counsel in any future dispute that accessibility is a considered, ongoing practice at your organization — not an afterthought.</p>
<h2>The Legal Landscape: When Is an Accessibility Statement Required?</h2>
<p>The answer to "do I legally need an accessibility statement?" depends heavily on where you operate, who your audience is, and which laws apply to you. The picture has changed significantly in the past two years, and the trajectory is clear: requirements are tightening globally.</p>
<p>In the United States, the most direct legal obligation for state and local governments comes from the Department of Justice's April 2024 final rule under Title II of the ADA, which clarified that government websites and mobile apps must conform to WCAG 2.1 Level AA. Publishing an accessibility statement and establishing governance around digital accessibility is part of that compliance posture. Compliance deadlines under this rule fall in April 2026 for larger entities and April 2027 for smaller ones. For private businesses covered by ADA Title III, while a specific accessibility statement is not explicitly mandated by statute, the absence of one has been used by plaintiffs' attorneys as evidence that an organization's broader accessibility efforts are lacking — making it a meaningful legal risk factor.</p>
<p>In the European Union, the picture is even more explicit. The EU Web Accessibility Directive has required public sector bodies in member states to publish accessibility statements for several years. Now, the European Accessibility Act — which came into full enforcement on June 28, 2025 — extends accessibility obligations to private businesses across sectors including e-commerce, banking, transport, and telecommunications. Any company that offers products or services to EU-based customers, regardless of where the company is headquartered, is in scope. Think of the EAA as the GDPR for digital accessibility: a sweeping, cross-border regulation that does not care where your servers are located. The EAA aligns with WCAG 2.1 Level AA as its technical benchmark for web and mobile content.</p>
<p>In the United Kingdom, the Public Sector Bodies Accessibility Regulations 2018 explicitly require all government and public-sector websites and apps to meet WCAG 2.1 AA standards <em>and</em> publish an accessibility statement. Canada's AODA in Ontario, Section 508 of the Rehabilitation Act for US federal contractors, and various other national frameworks add further layers. If you have a global audience, assume that at least one applicable law requires a statement from you.</p>
<blockquote>Even where no law explicitly mandates an accessibility statement for your specific organization, the absence of one increasingly looks like negligence — not neutrality. It is a low-cost, high-signal step that every website owner should take.</blockquote>
<h2>Why Your Accessibility Statement Matters Beyond Compliance</h2>
<p>Legal obligation is the floor, not the ceiling. There are compelling business and ethical reasons to have a well-crafted accessibility statement that go beyond simply avoiding lawsuits.</p>
<p>First, consider your users. Approximately 1.3 billion people worldwide live with some form of disability. Many of them have learned, through hard experience, to look for an accessibility statement before trusting a new website with their time or their money. A clear, honest statement tells them what assistive technologies your site has been tested with, who to contact if something breaks, and how seriously your organization treats the issue. It reduces friction and builds trust at the very moment a user with a disability is deciding whether to stay on your site.</p>
<p>Second, there is the reputational dimension. Not having an accessibility statement — or having one that is obviously templated, never updated, and makes commitments your site clearly does not keep — sends a negative signal to customers, employees, and partners who care about inclusion. Conversely, a thoughtful, regularly maintained statement is evidence of genuine organizational commitment. Leading organizations like Barclays and Roche publish statements that acknowledge their current limitations honestly while describing specific steps underway to address them. That transparency builds more goodwill than a statement claiming perfect compliance ever could.</p>
<p>Third, your accessibility statement creates an internal accountability mechanism. When you publicly commit to a standard, a testing methodology, and a response timeline for user-reported issues, you are creating expectations that your own teams have to meet. That is a feature, not a bug. Accessibility programs that lack external commitments tend to drift; those with public statements tend to stay on track.</p>
<p>Finally, there is SEO and usability to consider. Accessibility best practices — semantic HTML, proper heading structures, descriptive alt text, clear link labels — correlate strongly with search engine ranking signals. A website built with accessibility in mind tends to be a better-performing website across the board.</p>
<h2>What to Include: The Essential Components</h2>
<p>There is no single mandatory template for a private-sector accessibility statement, but the W3C's Web Accessibility Initiative provides the clearest guidance on what a statement should contain. Below is a breakdown of every component you should address, along with the reasoning behind each.</p>
<p><strong>A commitment statement.</strong> Open with a clear, human declaration of your organization's commitment to digital accessibility. Do not bury it. This is what users with disabilities — and plaintiff's counsel — will read first. Avoid corporate boilerplate. State specifically that you are working toward an inclusive experience for users with visual, auditory, physical, cognitive, neurological, and speech disabilities.</p>
<p><strong>The standard you are targeting.</strong> Name the specific version of WCAG you are aiming for — ideally WCAG 2.1 Level AA as a minimum, with WCAG 2.2 Level AA as the current best practice. Specify your conformance level honestly. If you are fully conformant, say so. If you are partially conformant, say that too and describe what areas fall short. Making false claims about conformance in your statement is worse than disclosing known gaps — it eliminates the good faith defense in litigation.</p>
<p><strong>Known limitations.</strong> This is the section most organizations get wrong. Either they list no limitations at all (implausible for almost any real website) or they use technical WCAG criterion numbers that mean nothing to users. The W3C recommends plain language: instead of "WCAG Success Criterion 1.2.2 is not met," say "some of our older videos do not have captions." Be specific. Be honest. Users will appreciate knowing in advance, and it protects you legally by demonstrating good faith.</p>
<p><strong>What you have done to address accessibility.</strong> Describe your actual efforts: have you conducted a third-party audit? Do you test with screen readers? Have you trained your content team? Do you use an accessibility overlay widget to provide additional assistive features? Detail the specific measures your organization takes. This section transforms your statement from a passive promise into active evidence of a compliance program.</p>
<p><strong>Technical environment.</strong> Note the browsers, operating systems, and assistive technologies your site has been tested with. Screen readers behave differently across browser combinations, and documenting your tested environments manages expectations while demonstrating rigor.</p>
<p><strong>Contact information.</strong> This may be the single most important section. Make it easy for users to report accessibility barriers. Provide multiple channels — email, phone, and ideally a web form that is itself fully accessible. Specify a response timeframe and honor it. Research consistently shows that the faster an organization responds to accessibility complaints, the less likely that complaint is to become a lawsuit. Do not route these contacts to a general mailbox that nobody monitors.</p>
<p><strong>Third-party content.</strong> If your site embeds third-party widgets, social media feeds, maps, or other content that you do not control, acknowledge this and clarify that you cannot guarantee the accessibility of that content. You can still describe any steps you take to select accessible third-party tools.</p>
<p><strong>Date of last review.</strong> Include a visible "last updated" date. An accessibility statement without a date looks — and may be — stale. Commit to reviewing and updating it at least annually, and after any significant redesign or content overhaul.</p>
<p><strong>References to applicable laws.</strong> Depending on your jurisdiction and audience, reference the relevant legal frameworks: the ADA, Section 508, the EAA, the UK Accessibility Regulations, AODA, or others. This shows legal awareness and helps users understand the regulatory context.</p>
<h2>A Structural Template You Can Adapt</h2>
<p>The following is a clean, semantic HTML structure you can adapt for your own accessibility statement page. Replace the placeholder values with accurate information specific to your organization and website.</p>
<pre><code><h1>Accessibility Statement</h1>
<p>
[Organization Name] is committed to ensuring digital accessibility
for people with disabilities. We continually improve the user experience
for everyone and apply relevant accessibility standards.
</p>
<h2>Conformance Status</h2>
<p>
We aim to conform to the Web Content Accessibility Guidelines (WCAG)
2.1 Level AA. These guidelines explain how to make web content more
accessible to people with disabilities. Our current conformance status
is: [fully conformant / partially conformant — describe known gaps].
</p>
<h2>Known Limitations</h2>
<p>
Despite our best efforts, some content may not yet be fully accessible:
</p>
<ul>
<li>[Example: Some older PDF documents do not have text
equivalents. We are converting these on a rolling basis.]</li>
<li>[Example: Videos published before [date] may not have
accurate captions. We are prioritizing recaptioning.]</li>
</ul>
<h2>Measures We Take</h2>
<ul>
<li>Annual third-party accessibility audits against WCAG 2.1 AA</li>
<li>Manual testing with screen readers (NVDA, JAWS, VoiceOver)</li>
<li>Automated scanning on each deployment</li>
<li>Accessibility widget providing user-controlled display options</li>
<li>Staff training on accessible content creation</li>
</ul>
<h2>Technical Specifications</h2>
<p>
This website has been tested on the following environments:
</p>
<ul>
<li>Chrome + NVDA on Windows 11</li>
<li>Safari + VoiceOver on macOS and iOS</li>
<li>Firefox + JAWS on Windows 11</li>
</ul>
<h2>Feedback and Contact</h2>
<p>
If you experience any accessibility barriers on this website, please
contact us. We aim to respond within 2 business days.
</p>
<ul>
<li>Email: <a href='mailto:[email protected]'>
[email protected]</a></li>
<li>Phone: +1 (555) 000-0000</li>
</ul>
<h2>Formal Complaints</h2>
<p>
If you are not satisfied with our response, you may contact the
relevant enforcement authority in your jurisdiction.
</p>
<p><em>This statement was last reviewed on [Month YYYY].</em></p></code></pre>
<h2>Common Mistakes to Avoid</h2>
<p>Most accessibility statements that exist on the web today are either absent, plagiarized from a template without modification, or actively misleading. Here are the specific pitfalls to sidestep.</p>
<p><strong>Claiming full conformance when you are not fully conformant.</strong> This is the most dangerous mistake. Automated tools catch roughly 30–40% of WCAG issues at best, which means a site that passes automated testing may still have significant barriers. If your statement claims full WCAG 2.1 AA conformance and a user or plaintiff can demonstrate otherwise, that false claim amplifies your legal exposure rather than reducing it. Accurate partial conformance claims, paired with a clear remediation roadmap, are both more honest and more defensible.</p>
<p><strong>Making the statement page itself inaccessible.</strong> This happens more often than you would expect. The accessibility statement should itself pass WCAG. Test the page, check the color contrast, verify keyboard navigation, and make sure screen readers can parse the headings correctly. An inaccessible accessibility statement is, at minimum, embarrassing — and at worst, evidence in a complaint.</p>
<p><strong>Providing no real contact mechanism.</strong> A statement that invites users to "contact us" with a broken form or a generic info@ email address that nobody monitors is worse than useless. Users who try to report a barrier and cannot get a response are far more likely to escalate to a regulator or an attorney.</p>
<p><strong>Never updating it.</strong> A statement dated three years ago that references technologies or standards that have since been superseded erodes trust immediately. Build a calendar reminder to review your statement at minimum once per year, and immediately after any significant site redesign.</p>
<p><strong>Burying it where no one can find it.</strong> The W3C recommends linking to your accessibility statement from multiple prominent locations: the footer, the help menu, the sitemap, and the about page. Use consistent link text — "Accessibility Statement" or "Accessibility" — so users who know to look for it can find it quickly.</p>
<h2>Where Accsible Fits Into Your Accessibility Strategy</h2>
<p>An accessibility statement is documentation of your commitment, but commitment without implementation is just words. This is where a tool like Accsible's overlay widget SDK comes in as one layer of a broader accessibility strategy.</p>
<p>Accsible allows you to embed a configurable accessibility widget on your site that gives users direct control over their browsing experience — adjusting font sizes, contrast settings, cursor size, animation reduction, and more. These user-facing controls extend your site's usability for people with a range of vision, motor, and cognitive needs. Importantly, when you include an accessibility widget in your toolchain, your accessibility statement becomes more specific and credible: you can name the specific features the widget provides, describe the environments it has been tested in, and demonstrate that you have taken active, technical steps toward inclusion.</p>
<p>That specificity matters. Courts, regulators, and users all respond better to statements that describe concrete measures than to vague pledges. Your statement should reference the widget, what it does, and which user needs it addresses — alongside your audit program, your testing methodology, and your human contact point for feedback. The widget is not a substitute for semantic, well-structured underlying code, but it is a meaningful, documented layer of effort that belongs in your statement.</p>
<blockquote>Accessibility is a program, not a product. Your statement documents that program. Every tool, audit, training session, and feedback loop you put in place makes your statement more credible — and your site genuinely more inclusive.</blockquote>
<h2>Keeping Your Statement Current: A Maintenance Checklist</h2>
<p>An accessibility statement is a living document. The moment your site changes — a new checkout flow, a redesigned navigation, a new embedded video player — the accuracy of your statement is potentially affected. Build a maintenance rhythm into your accessibility program so the statement always reflects reality.</p>
<ul>
<li><strong>After each major release or redesign:</strong> Review the Known Limitations section and the Technical Specifications. Update tested environments if browsers or assistive technologies have changed.</li>
<li><strong>Annually:</strong> Commission or conduct a full accessibility audit. Refresh the conformance status and the measures section to reflect current tools, processes, and results. Update the "last reviewed" date.</li>
<li><strong>When standards change:</strong> WCAG 2.2 is now published and WCAG 3.0 is in development. When regulatory bodies update their technical standards, update your statement to reflect the version you are targeting and your plan for migration.</li>
<li><strong>When laws change:</strong> The EAA, ADA Title II deadlines, and other regulations are actively evolving. If new requirements apply to your organization, update the legal references in your statement accordingly.</li>
<li><strong>When contact details change:</strong> Immediately update any email addresses, phone numbers, or form links. A broken contact channel in an accessibility statement is both a usability failure and a legal risk.</li>
</ul>
<p>Logging accessibility feedback you receive — the issues users report, how you responded, and how long remediation took — also creates a paper trail that demonstrates good faith. If your organization is ever challenged on its accessibility practices, that record can be invaluable.</p>
<h2>Key Takeaways</h2>
<ul>
<li><strong>An accessibility statement is both a legal risk management tool and a user trust signal.</strong> In many jurisdictions — including for EU-market businesses under the EAA and US public entities under the ADA Title II rule — some form of public accessibility commitment is now required or strongly implied by law.</li>
<li><strong>Honesty about limitations protects you more than overclaiming.</strong> Stating that you are partially conformant with a clear remediation plan is more legally defensible than falsely claiming full WCAG compliance. Courts and regulators respond well to demonstrated good faith.</li>
<li><strong>Make your contact mechanism real and monitored.</strong> Provide multiple ways to report barriers — email, phone, a web form — and commit to a specific response timeframe. Fast responses to user-reported issues dramatically reduce legal escalation risk.</li>
<li><strong>Your accessibility statement page must itself be accessible.</strong> Test it for WCAG conformance, verify keyboard navigation, check color contrast, and ensure screen reader compatibility before you publish.</li>
<li><strong>Treat the statement as a living document, not a one-time task.</strong> Review it after every major site change, annually at minimum, and whenever applicable laws or WCAG standards are updated. Keep the "last reviewed" date visible and accurate.</li>
</ul>