A public declaration that names your site’s conformance target, discloses known barriers, and provides a direct channel for reporting problems is what most auditors look for first. Most organizations publish one and then forget it exists. That gap between publication and maintenance is where legal exposure and user distrust quietly build.
The sections below walk through the legal drivers, required content elements, drafting methods, and maintenance practices that separate a defensible statement from a liability.
The Accessibility Statement as a Legal and Ethical Document
A statement sits at the intersection of compliance and communication. It tells someone using a screen reader whether your content will work with their assistive technology, and it tells a plaintiff’s attorney whether your organization has acknowledged its obligations. Both functions happen simultaneously in the same document.
Think of it as a contract of transparency rather than a guarantee of perfection. The statement declares a specific WCAG version and conformance level as your target, lists content that does not yet meet that target, and explains why. It also names a feedback mechanism where someone can report a barrier they encounter on your site.
An accessibility statement is not an audit report or a VPAT. An audit documents test results in technical detail. A VPAT maps product features against specific standards for procurement purposes. The statement is a public-facing summary that translates those findings into plain language for the people actually using your site.
This distinction matters because conflating the three leads to statements that are either too technical for end users or too vague to satisfy legal scrutiny. Your statement should reference audit findings without reproducing them in full. The goal is honest disclosure in language a person with a disability can act on immediately.
Laws and Standards That Drive Statement Requirements
No single global law mandates accessibility statements, but a patchwork of regulations creates strong pressure to publish one. The specific obligation depends on your jurisdiction, sector, and whether you serve public-sector clients.
European Mandates
The EU Web Accessibility Directive (Directive 2016/2102) requires public-sector bodies to publish accessibility statements for every website and mobile application. These statements must follow a specific template defined in EN 301 549 and include a description of inaccessible content, an explanation of why it remains inaccessible, and a feedback mechanism. The European Accessibility Act extends similar obligations to private-sector e-commerce and digital services, with enforcement beginning in June 2025.
US Legal Landscape
The Americans with Disabilities Act does not explicitly require a written statement. Neither does Section 508 of the Rehabilitation Act. However, ADA-related lawsuits have surged past 4,000 filings per year in federal courts alone, and defendants who can point to a published statement with documented remediation efforts tend to fare better in settlement negotiations. The statement functions as evidence of good-faith effort toward reasonable accommodations.
How Conformance Levels Appear in Statements
Most organizations cite WCAG 2.1 Level AA as their conformance target. WCAG 2.2, published in October 2023, adds nine new success criteria focused on cognitive disabilities and small touch targets. Referencing the newer version signals current awareness, but only claim conformance to criteria your site actually passes. The table below summarizes how different frameworks reference WCAG levels.
| Framework | Applies To | WCAG Level Referenced | Statement Mandate |
|---|---|---|---|
| EU Web Accessibility Directive | Public-sector websites and apps | AA (EN 301 549) | Required |
| European Accessibility Act | Private e-commerce, banking, transport | AA | Required (2025) |
| ADA (Title III) | Places of public accommodation | AA (de facto standard) | Not explicit, but expected |
| Section 508 | US federal agencies and contractors | AA | Required for covered entities |
Core Elements Every Compliant Statement Must Contain
Five components form the backbone of a defensible statement. Omitting any one of them weakens both the legal protection and the practical value the document provides to someone encountering a barrier on your site.
- Conformance target: Name the exact WCAG version (2.1 or 2.2) and level (A, AA, or AAA) your site aims to meet. Vague language like “we strive for accessibility” without a named standard offers no measurable commitment.
- Known limitations: List specific content or features that do not conform, along with the reason. For example, a PDF library uploaded before 2020 may lack proper heading structure, and your statement should say so.
- Feedback mechanism: Provide a working email address, phone number, or form where someone can report a barrier. A dead link here defeats the entire purpose of the document.
- Assessment date: State when the last audit or evaluation took place. This timestamp tells anyone reviewing the statement whether the information reflects current conditions.
- Compatibility notes: Specify which browsers and assistive technologies your site supports. Mentioning screen reader compatibility with NVDA, JAWS, or VoiceOver gives concrete guidance to the person relying on that technology.
A website accessibility statement example from a well-maintained site will include all five elements in plain language, organized with short headings so someone using a screen reader can jump directly to the section they need. The W3C Web Accessibility Initiative provides a reference structure that demonstrates this layout effectively.
Drafting the Statement from Scratch or with a Generator
The W3C offers a free accessibility statement generator that walks you through a series of prompts and produces a structured draft. For small sites with straightforward content, this tool covers the basics in under 15 minutes. Larger organizations with complex content ecosystems will need to customize significantly beyond what the generator produces.
Structuring for Readability
Write in plain language at a sixth-to-eighth-grade reading level. Short paragraphs, descriptive subheadings, and bullet points make the document scannable for someone navigating with keyboard navigation alone. Avoid legal jargon that excludes the very people the statement exists to serve. A person encountering a barrier at 11 p.m. needs clear instructions, not corporate boilerplate.
Placement and Linking
Link the statement from every page, typically in the footer. The EU directive specifically requires that the statement be “easily accessible” and available on every page of the website. Burying it three clicks deep or hiding it behind a navigation menu undermines both compliance and trust.
Tone and Honesty
Acknowledge gaps without sounding defensive. A statement that says “Our video content published before March 2023 lacks captions, and remediation is in progress” builds more credibility than one claiming full conformance without evidence. Your tone signals whether your organization treats digital inclusion as a genuine commitment or a checkbox exercise.
A well-drafted statement earns trust only as long as it reflects what users actually encounter on the site.
Keeping the Statement Accurate Over Time
A statement published once and never revisited becomes a liability rather than a safeguard. Courts and regulatory bodies treat outdated claims as evidence of negligence, not good faith. The maintenance cadence below keeps the document aligned with your site’s actual state.
- Annual review minimum: Schedule a formal review at least once per year, ideally timed to coincide with your accessibility audit cycle.
- Trigger-based updates: Revise the statement immediately after a major site redesign, a platform migration, or the launch of new content types such as interactive tools or embedded media.
- Audit date tracking: Update the assessment date each time a third-party evaluation is completed. Link to the summary report where possible.
- Remediation documentation: When a previously listed limitation is fixed, remove it from the limitations section and note the resolution date. This creates a paper trail showing active progress.
- Version alignment: When WCAG 2.2 success criteria become relevant to your conformance claim, update the referenced version and adjust your limitations list accordingly.
An outdated statement claiming full WCAG 2.1 AA conformance while your site still has missing alternative text on product images creates a worse legal position than having no statement at all. It demonstrates awareness of the standard paired with a failure to maintain it.
Common Mistakes That Undermine an Otherwise Solid Statement
Even well-intentioned organizations sabotage their own efforts through predictable errors. Each mistake below has appeared in real enforcement actions or user complaints documented by disability advocacy groups.
- Claiming full conformance without an audit: Stating “our site is fully WCAG 2.1 AA compliant” without a supporting third-party assessment invites scrutiny. Automated tools catch roughly 30% of WCAG failures; manual testing by experienced evaluators is necessary to support a conformance claim.
- Dead feedback channels: A contact form that returns a 404 error or an email address that bounces tells the person reporting a barrier that their experience does not matter. Test your feedback mechanism quarterly.
- Buried placement: A statement accessible only through a sitemap or an obscure subdirectory fails the “easily accessible” requirement and frustrates the person who needs it most.
- Legal jargon: Dense indemnification language written for counsel alienates the person with a disability who is trying to determine whether they can complete a task on your site. The ADA it should serve both functions, but readability for end users takes priority in structure and tone.
- Ignoring version updates: Referencing WCAG 2.0 in 2025 signals that no one has reviewed the document in years. Update the referenced version and reassess against new success criteria.
One mid-size retailer learned this the hard way in 2023 when a demand letter cited their statement’s claim of “full conformance” alongside screenshots of 47 product images missing alternative text. The gap between the claim and the reality strengthened the plaintiff’s position considerably.
Putting It Together
The single most important insight is this: an it is a living document, not a one-time publication. Its value depends entirely on whether the claims it makes match the experience your site actually delivers today. Treat it with the same maintenance rigor you apply to your privacy policy, and it becomes both a shield against legal risk and a genuine invitation to the people who depend on barrier-free access.
FAQ
What should be included in an accessibility statement?
A compliant statement names your WCAG version and conformance level, lists known limitations with reasons, provides a working feedback mechanism, states the date of your last assessment, and notes which browsers and assistive technologies your site supports.
Is an accessibility statement legally required?
The EU Web Accessibility Directive and European Accessibility Act mandate statements for covered entities. In the US, no federal law explicitly requires one, but ADA litigation and Section 508 procurement expectations make publishing one a practical necessity for most organizations.
Where should the accessibility statement be placed on a website?
Link it from every page, typically in the footer. The EU directive requires the statement to be easily accessible from all pages. Placing it behind multiple navigation layers or in an obscure subdirectory fails this requirement.
What is the difference between an accessibility statement and an accessibility policy?
A statement is a public-facing disclosure of your site’s current conformance status and known barriers. A policy is an internal governance document that defines roles, responsibilities, and procedures for maintaining accessibility across your organization. The statement references the policy’s outcomes; the policy drives the work behind them.
How often should an accessibility statement be updated?
Review it at least annually and immediately after any major redesign, platform migration, or new content launch. Each update should refresh the assessment date, adjust the limitations list, and confirm that the feedback mechanism still functions.
Does a website need an accessibility statement if it is already accessible?
Yes. Even a fully conformant site benefits from a published statement because it documents the conformance target, provides a feedback channel for edge cases, and demonstrates ongoing commitment. The statement also protects against claims that accessibility was never considered.
