An accessibility statement is a public page on your website that explains your commitment to digital accessibility, describes the current state of your site against recognized standards like WCAG, and tells users with disabilities how to get help if they encounter barriers. Think of it as the accessibility equivalent of a privacy policy: it is both a legal requirement in many jurisdictions and a practical tool that builds trust with your users. With the European Accessibility Act now enforceable since June 2025, ADA Title II rules requiring WCAG 2.1 AA for US government sites by April 2026, and over 4,600 web accessibility lawsuits filed in the US in 2024 alone, having a proper accessibility statement is no longer optional for most organizations. This guide walks you through exactly what to include, provides a ready-to-use template, and covers the differences between jurisdictions so your statement holds up no matter where your users are.
What Is an Accessibility Statement and Why Does It Matter
An accessibility statement is a dedicated page on your website where you publicly declare your organization's approach to digital accessibility. At minimum, it tells visitors which accessibility standard you follow, what known barriers exist on your site, and how to contact you if something does not work with assistive technology.
The reason it matters goes beyond compliance checkboxes. For people with disabilities, an accessibility statement signals whether an organization takes their needs seriously or merely pays lip service. A statement that honestly acknowledges known issues and provides a clear contact path is far more useful than a vague pledge buried in a footer.
From a legal perspective, accessibility statements are explicitly required in several jurisdictions. The EU Web Accessibility Directive mandates them for all public sector websites and mobile apps. The European Accessibility Act extends similar expectations to private sector digital services. In the UK, public sector bodies must publish accessibility statements that follow a specific government template. In the US, while no federal law explicitly requires an accessibility statement, publishing one demonstrates good faith and can be a meaningful factor if your organization faces an ADA complaint.
There is also a practical benefit that many organizations overlook: an accessibility statement creates an organized feedback channel. When users report accessibility problems through the contact information in your statement, you get actionable bug reports that help you improve the experience for everyone. Without that channel, users simply leave and you never know why.
Legal Requirements by Jurisdiction
The legal landscape for accessibility statements varies significantly depending on where your organization operates and where your users are located. Here is what each major jurisdiction requires.
European Union: EAA and Web Accessibility Directive
The EU has the most prescriptive requirements. The Web Accessibility Directive, which applies to public sector bodies, requires an accessibility statement that includes: a declaration of which parts of the content are not accessible and why, a description of any accessible alternatives provided, a link to the enforcement procedure where users can file complaints, and a date when the statement was last reviewed.
The European Accessibility Act, enforceable since June 28, 2025, extends accessibility obligations to private sector companies selling products or services in the EU. Under the EAA, providers must document how their digital products and services meet accessibility requirements and provide contact information for users to report issues. Fines vary by member state: up to 100,000 euros in Germany under the BFSG, up to 300,000 euros in Spain, and up to 250,000 euros in France with additional daily penalties for ongoing non-compliance.
The technical standard referenced across EU legislation is EN 301 549, which maps to WCAG 2.1 Level AA. Your accessibility statement should reference this standard explicitly.
United Kingdom: Equality Act and Public Sector Requirements
The UK requires all public sector websites and mobile apps to publish an accessibility statement following the model provided by the Government Digital Service. The statement must list any inaccessible content with explanations, describe how the organization plans to fix the issues, and include a contact method for reporting accessibility problems. Public sector statements must be reviewed and updated at least every 12 months.
For private sector organizations, the UK Equality Act 2010 prohibits discrimination based on disability but does not explicitly mandate an accessibility statement. However, publishing one is strongly recommended as evidence of reasonable adjustments. UK businesses selling into the EU must also consider EAA compliance for their digital services.
United States: ADA and Section 508
Unlike the EU and UK, the United States does not have a specific statutory requirement for accessibility statements on commercial websites. The ADA requires that places of public accommodation be accessible to people with disabilities, and federal courts have consistently extended this to websites, but the law does not prescribe a particular statement format.
That said, publishing an accessibility statement is a recognized best practice that signals good faith. The DOJ finalized ADA Title II rules in April 2024 requiring WCAG 2.1 AA compliance for state and local government websites, with the first deadline arriving April 26, 2026 for entities serving populations over 50,000. Federal agencies are governed by Section 508, which also references WCAG.
A Voluntary Product Accessibility Template (VPAT) serves a complementary role in the US market. Where an accessibility statement is user-facing, a VPAT is a technical document typically shared during procurement. Organizations selling to government agencies frequently need both.
What to Include in Your Accessibility Statement: Section by Section
A thorough accessibility statement covers several core sections. You can adapt the depth based on your jurisdiction and organization size, but skipping any of these sections weakens the statement's usefulness.
Commitment and Scope
Start with a clear, plain-language declaration of your commitment to accessibility. Name the specific website or application the statement covers. If your organization operates multiple digital properties, each one should have its own statement or be explicitly listed in scope.
Avoid vague corporate language. A statement that says we are committed to ensuring digital accessibility for all users is weaker than we are committed to making example.com accessible to people with disabilities in conformance with WCAG 2.2 Level AA. The second version tells the reader exactly what standard you are working toward.
Conformance Standard and Level
State which accessibility standard you follow and at what level. For most organizations, this will be WCAG 2.2 Level AA, which is the current W3C Recommendation and covers the requirements of both the EAA (via EN 301 549) and ADA expectations.
WCAG defines three conformance levels. Level A covers the most fundamental requirements: text alternatives for images, keyboard operability, and seizure safety. Level AA adds contrast requirements, text resizing, consistent navigation, and error handling. Level AAA includes the strictest criteria like sign language interpretation and enhanced contrast, but the W3C does not recommend it as a blanket target because some content types cannot meet all AAA criteria.
Be honest about your conformance status. WCAG allows three declarations: fully conformant (all criteria met), partially conformant (most criteria met with some exceptions), and non-conformant. Most real-world websites are partially conformant, and saying so honestly is far better than claiming full conformance when it is not true.
Known Limitations and Alternatives
This is the section most organizations get wrong, either by leaving it empty or by being too vague. List specific accessibility barriers you are aware of, explain why they exist, and describe what users can do as a workaround.
A good example: Our embedded video player does not currently support keyboard-operated volume control. We are working with our video provider to resolve this by Q2 2026. In the meantime, users can adjust volume using their operating system controls.
A bad example: Some parts of this website may not be fully accessible. We are working on improvements.
The difference is actionable information. Users with disabilities are accustomed to navigating imperfect digital experiences. What frustrates them is not knowing which barriers exist and having no alternative path. Transparency about limitations actually builds more trust than pretending everything works perfectly.
Feedback and Contact Information
Provide multiple ways for users to report accessibility issues. Include at minimum an email address and a phone number. Consider adding a web form specifically for accessibility feedback. Remember that the person reporting the issue may be using assistive technology, so the contact method itself must be accessible.
Name a specific person or team responsible for handling accessibility feedback, and commit to a response timeline. A statement that says our accessibility team will respond within 5 business days is more credible than contact us if you have any issues.
If you are in the EU, include a link to the national enforcement body where users can file a complaint if they are not satisfied with your response. Each EU member state designates its own enforcement authority.
Assessment Methods and Date
Describe how your site was evaluated. Options include self-assessment using automated tools, external audit by an accessibility consultancy, or user testing with people who have disabilities. Stating the method adds credibility. An accessibility statement backed by a third-party audit carries more weight than one based purely on an automated scan.
Always include the date the statement was last reviewed. A statement without a date, or with a date from three years ago, suggests the organization is not actively maintaining accessibility. Best practice is to review and update your statement at least annually, and more frequently when significant changes are made to your website.
Ready-to-Use Accessibility Statement Template
Here is a template you can adapt for your organization. Replace the bracketed placeholders with your specific information.
Accessibility Statement for [Organization Name]
[Organization Name] is committed to ensuring digital accessibility for people with disabilities. We continually improve the user experience for everyone and apply the relevant accessibility standards.
Conformance Status: [Organization Name] aims to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. [We are currently partially conformant / We are fully conformant] with WCAG 2.2 Level AA. Partially conformant means that some parts of the content do not fully conform to the accessibility standard.
Known Limitations: The following areas of the website have known accessibility limitations. We are actively working to resolve them: - [Description of limitation 1] due to [reason]. We expect to fix this by [date]. In the meantime, [workaround]. - [Description of limitation 2] due to [reason]. We expect to fix this by [date]. In the meantime, [workaround].
Feedback: We welcome your feedback on the accessibility of [website/application name]. Please let us know if you encounter accessibility barriers: - Email: [accessibility email] - Phone: [phone number] - [Contact form URL] We aim to respond to accessibility feedback within [X] business days.
Assessment Method: This website was assessed for accessibility using [automated testing tools / a third-party accessibility audit by (auditor name) / user testing with assistive technology users] on [date of last assessment].
Enforcement Procedure: [For EU sites: If you are not satisfied with our response, you can file a complaint with (national enforcement authority name and link).]
This statement was last reviewed on [date].
Common Mistakes to Avoid
After reviewing hundreds of accessibility statements across industries, certain patterns of failure come up repeatedly.
Using technical jargon instead of plain language. Your statement is for end users, not accessibility consultants. Instead of writing WCAG Success Criterion 1.2.2 was not met, write our videos do not yet have captions. Keep the language clear enough that someone without technical background understands what works and what does not.
Making the statement itself inaccessible. This happens more often than you would expect. Accessibility statements published as PDFs without proper tagging, pages with poor color contrast, or statements that cannot be reached by keyboard navigation undermine the entire point. Your accessibility statement page should be one of the most accessible pages on your site.
Claiming full conformance when it is not true. Every non-trivial website has some accessibility gaps. Claiming full WCAG 2.2 AA conformance when you have known issues is dishonest and creates legal risk. Courts and regulators view false claims more negatively than honest acknowledgment of partial conformance with a clear remediation plan.
Burying the statement where nobody can find it. Link to your accessibility statement from your website footer on every page, and consider adding it to your main navigation, sitemap, and help section. If users cannot find it, it does not serve its purpose.
Treating it as a one-time document. An accessibility statement that was last updated in 2022 tells users that accessibility is not an active priority. Review and update yours at least annually, and any time you make significant changes to your website or resolve known barriers.
Forgetting to include contact information. A statement without a way to report problems is just a declaration with no accountability. The contact section is arguably the most important part of the statement because it creates a channel for real user feedback.
Free Tools to Generate Your Accessibility Statement
If you prefer a guided approach over starting from scratch, several free tools can help you create an accessibility statement.
The W3C WAI Accessibility Statement Generator is the gold standard. Maintained by the World Wide Web Consortium, it walks you through each required section and generates a standards-compliant statement. No account required, and none of your information is stored on their servers.
Accessible Web offers a free generator that produces statements aligned with common legal frameworks. The output is straightforward and covers the essential sections.
Termly provides a generator oriented toward US businesses, with a focus on ADA and WCAG compliance language. It produces a ready-to-publish page you can embed on your site.
Siteimprove offers an accessibility statement generator as part of their toolkit, creating a statement in just a few clicks based on your input.
Whichever tool you use, treat the output as a starting point, not a finished product. Generated statements need customization to accurately reflect your specific situation, known barriers, and remediation timeline. A generic statement that does not mention your actual accessibility state is nearly as useless as no statement at all.
How to Keep Your Statement Current
An accessibility statement is a living document. Here is a practical cadence for maintaining it.
Review quarterly: Every three months, check whether your statement still accurately reflects the state of your website. Have you fixed barriers that are still listed as known limitations? Have new features introduced new accessibility issues? Update the statement to match reality.
Update after every audit: Whenever you run an accessibility assessment, whether automated or manual, update your statement with the results. Change the conformance status if warranted, update the known limitations section, and refresh the last reviewed date.
Update after major site changes: A redesign, a new content management system, a new checkout flow, or any other significant change to your website should trigger a statement review. New code means new potential barriers.
Connect your accessibility statement to a regular scanning routine. Running automated WCAG scans on a weekly or monthly basis catches regressions before they accumulate. Our free accessibility checker at web-accessibility-checker.com lets you scan your pages against WCAG 2.2 and track issues over time, making it straightforward to keep your statement accurate.