An accessibility statement is a public page that explains your organization’s commitment to digital accessibility, states your current conformance level honestly, and gives visitors a way to report barriers they run into. It should take a visitor two minutes to read and tell them exactly who to contact if something on your site doesn’t work for them. Below is a structure you can adapt directly, along with notes on what to avoid.
What to include
A solid accessibility statement covers five things: a short commitment statement, your current conformance status against a named standard (usually WCAG 2.1 or 2.2 AA), how you assessed that status, known limitations if any exist, and contact information for feedback. Skipping the conformance status and just saying “we care about accessibility” is the single most common weakness in statements we see; it reads as a marketing line rather than documentation.
A template you can adapt
Replace the bracketed sections with details specific to your organization.
Accessibility statement for [organization name]
[Organization name] is committed to ensuring digital accessibility for people with disabilities. We are continuing to improve the user experience for everyone and apply the relevant accessibility standards.
Conformance status: This website aims to conform to WCAG 2.1 Level AA. [State one of: “fully conforms,” “partially conforms,” or “does not currently conform,” and briefly explain why if it’s not full conformance.]
Known limitations: [List any known issues, e.g. “Some older PDF documents published before 2025 have not yet been remediated and may not be fully accessible to screen reader users. We are working through these on a rolling basis.”]
Feedback: We welcome your feedback on the accessibility of [site name]. Please let us know if you encounter accessibility barriers. Phone: [number] Email: [address] Postal address: [address] We try to respond to feedback within [X] business days.
Technical specifications: Accessibility of [site name] relies on HTML, CSS, JavaScript and WAI-ARIA for its operation with assistive technologies.
Assessment approach: [Organization name] assessed the accessibility of this website through [self-evaluation / an external audit / automated scanning combined with manual testing]. This statement was last reviewed on [date].
Things to avoid
Don’t claim “full compliance” or “100% ADA compliant” unless you’ve actually verified that through testing, ideally including manual testing rather than an automated scan alone. That kind of blanket claim has become a specific point of scrutiny; in 2025 the U.S. FTC ordered accessiBe to pay $1 million to settle charges tied partly to overstated claims about how much of a website its widget could automatically fix. The lesson generalizes well beyond that one case: a statement should describe what you’ve actually verified, not what you hope is true.
Also avoid burying the statement where nobody can find it. Link it from your site footer, and make sure the statement page itself is accessible (proper heading structure, readable contrast, no walls of unstructured text).
Generated statements vs. a statement backed by real testing
Several widget vendors, including UserWay and accessiBe, offer an accessibility statement generator as part of their product. These can be a genuinely useful starting point for structure and standard phrasing, especially for a small site without in-house legal or accessibility expertise. The gap to watch for is that a generated statement based on a quick automated scan can end up asserting a conformance level the site hasn’t actually earned through manual testing. If you’re using a generated statement, treat the conformance-status section as the part that needs the most editing, and update it once you know your real status rather than accepting a default claim.
For organizations further along, a statement written after an actual audit, whether from a testing-focused vendor or a widget-plus-manual-review provider like Wawsome, can state conformance with more confidence because there’s underlying evidence behind it. If you’re preparing a statement for EU public-sector or EAA-related purposes specifically, it’s worth aligning the conformance language with EN 301 549 terminology as well as WCAG, since that’s the standard EU reviewers and procurement teams will expect to see referenced.
Writing the conformance status section honestly
This is the part of the statement worth spending the most time on, and the part most templates leave vague on purpose. “Partially conforms” is a perfectly normal, honest thing to write, and it’s far more useful to a visitor (and far more defensible if a complaint ever arises) than an unqualified “fully accessible” claim you can’t actually back up. If you’ve run an audit, name the standard and version you tested against (WCAG 2.1 AA is the most common baseline) and give a general sense of scope, whether that was the whole site, a subset of key pages, or specific flows like checkout. If you haven’t run a formal audit yet, it’s fine to say so directly: “We have not yet completed a formal accessibility audit of this site. We are committed to doing so and will update this statement once that work is complete” is honest, useful information, and a reasonable interim statement while remediation work is underway.
Handling feedback once it comes in
The feedback section isn’t just a formality: publishing contact information means you should expect to actually receive reports, and having no internal process for handling them undermines the point of publishing a statement at all. Decide who on your team owns incoming accessibility feedback, set a realistic response-time expectation (and state it in the statement itself, as the template above does), and keep a simple log of what’s reported and how it was resolved. That log becomes useful evidence of an active, functioning accessibility program if it’s ever needed, and it also naturally feeds the “known limitations” section, since real user reports are often a better source of what’s actually broken than an automated scan alone.
Multi-language and multi-site considerations
If your organization operates in more than one language or maintains separate statements for different properties, keep the conformance-status wording consistent across versions rather than letting one language edition claim a higher conformance level than another by accident. This comes up frequently for EU-facing businesses managing statements across German, French, Italian and other markets, where a translation done independently of the original can drift from the actual current status. Reviewing all language versions together at the same time you do your annual update is a simple way to avoid that gap.
Where to publish it
Most organizations publish the statement as its own page, linked from the site footer on every page, sometimes duplicated in the site’s terms or privacy hub. EU public sector bodies covered by the Web Accessibility Directive are expected to publish one in a consistently findable location and keep it current; it’s a reasonable practice to follow even where it isn’t strictly mandated, since it signals to both users and, if it ever comes to it, to a court or regulator, that accessibility is something you’ve actually thought about rather than ignored.