What Is an Accessibility Statement and How to Write One

An accessibility statement is a public page on your website where you declare your commitment to accessibility, state which standard and conformance level you meet (usually WCAG 2.2 Level AA), list any known issues or content that is not yet conformant, and give visitors a way to report problems and get help. It is part transparency document, part user-support channel, and increasingly part legal requirement. The golden rule is honesty: a statement should describe your real conformance and your genuine gaps, never overclaim "fully accessible". This guide explains what an accessibility statement is for, exactly what to include section by section, the free W3C tool that makes writing one easy, and the legal context that is making them an expectation rather than a courtesy.

It assumes the groundwork from what web accessibility is and why it matters and what WCAG is and the difference between A, AA and AAA, since a statement is largely a claim about your WCAG conformance.

What an accessibility statement is for

A statement serves several audiences and purposes at once, which is why a good one is worth the effort:

• It tells disabled users what to expect. Someone using a screen reader or keyboard can read your statement, learn that you aim for WCAG 2.2 AA, and see which parts of the site may still have problems — so they are not blindsided by a barrier and know where to turn for help.
• It gives users a route to report problems and get an alternative. The single most user-respecting thing a statement does is provide a feedback channel: a way to say "this PDF is not accessible to me" and to request the information another way. That turns a dead end into a path forward.
• It demonstrates commitment and good faith. A clear, honest statement signals that the organisation takes accessibility seriously and is working at it, which matters reputationally and, in some legal contexts, as evidence of intent.
• It records your accessibility position. Internally, a statement is a useful artefact: it forces you to know your conformance level, your known issues, and how you assessed them.

What a statement is not is a substitute for actually being accessible. It is a description of reality, not a magic shield — which is exactly why honesty is non-negotiable.

What to include: the core sections

A thorough accessibility statement has a recognisable structure. The W3C's model (below) and most regulatory templates converge on the same sections. Here is what each one contains:

Section	What it should contain
Commitment	A short, plain statement that you are committed to accessibility and to making your content usable by everyone, including people with disabilities
Conformance status	The standard and version (e.g. WCAG 2.2), the target level (e.g. AA), and an honest status: fully conformant, partially conformant, or not yet conformant — with what "partially" means here
Known limitations	A frank list of areas, content or features that are not yet accessible, why, and any workaround or timeline — this is where honesty is most visible
Feedback & contact	How users can report accessibility problems and request accessible alternatives: an email, a form, a phone number, and a commitment to respond
Technical details	The technologies the site relies on and the browsers and assistive technologies it is designed to support (e.g. "tested with NVDA and VoiceOver")
Assessment approach	How accessibility was evaluated — self-assessment, automated tools, manual testing, third-party audit — and when
Date & legal info	The date the statement was prepared or last reviewed, and any legal or enforcement information relevant to your jurisdiction (e.g. how to escalate a complaint)

Commitment

Open with a brief, sincere statement of intent — that you want everyone to be able to use your site and are working to meet recognised accessibility standards. Keep it human and specific to your organisation rather than boilerplate.

Conformance status

This is the heart of the statement and the part people misuse most. State the standard (WCAG), the version (2.2), and the level you target (almost always AA — see what WCAG is and the difference between A, AA and AAA). Then state your status honestly using WCAG's own vocabulary:

• Fully conformant — the content meets the standard at the stated level with no known exceptions. (Genuinely rare; claim it only if true.)
• Partially conformant — most content conforms, but some parts do not yet. This is the honest status for most real, actively maintained sites.
• Non-conformant — the content does not yet meet the standard. Even this is better stated plainly than hidden.

Known limitations

List the specific things that are not yet accessible — for example, "some older PDF documents are not tagged for screen readers", "the interactive map is not fully keyboard operable", "third-party embedded content may not meet our standards". For each, ideally note a workaround (how to get the information another way) and, if you have one, a timeframe for fixing it. A statement that admits real gaps is more credible, not less, and it is far safer than pretending they do not exist.

Feedback and contact

Provide a clear, working way for users to report barriers and request help — an email address, a form, a phone number — and say how quickly you aim to respond. This section is the difference between a statement that helps users and one that merely talks about helping them. Keep the contact details current; a feedback channel that bounces is worse than none.

Technical and assessment details

Note the assistive technologies and browsers you have tested with and support, which sets honest expectations. And describe how and when you assessed accessibility — automated scans, manual keyboard and screen-reader testing, or a formal third-party audit (the kind of process covered in how to run an accessibility audit). Dating the statement matters because accessibility, and your conformance, change over time.

Legal and enforcement information

Where relevant, include how a user can escalate if they are not satisfied with your response. In regulated contexts (see below) there may be a specific complaints or enforcement route you are required to mention.

The W3C/WAI Accessibility Statement Generator

You do not have to write all of this from a blank page. The W3C's Web Accessibility Initiative (WAI) provides a free Accessibility Statement Generator — an online tool that walks you through each standard section, prompts you for the right information (your conformance level, known issues, contact details, assessment method and so on), and produces a structured, well-formed statement you can adapt and publish. It is the easiest and most reliable way to create a thorough statement, because it ensures you do not omit a section, and it reflects the W3C's own model for what a good statement contains. Use it as your starting framework, then tailor the wording to your organisation and fill in your genuine, tested details.

The legal context

Accessibility statements have moved from "nice to have" toward "expected", and in places "required":

• EU public sector. Under the EU Web Accessibility Directive, public-sector bodies are required to publish an accessibility statement in a prescribed format, including conformance status, known issues and a feedback mechanism.
• European Accessibility Act (EAA). The EAA extends accessibility obligations to a broad range of private products and services, and providing accessibility information is part of conforming and communicating in good faith.
• United States. While US law (the ADA, Section 508) does not always mandate a statement in the same prescriptive way, publishing one is widely treated as good practice and as evidence of a genuine accessibility effort — and it pairs naturally with the WCAG-AA target that ADA case law and Section 508 align with.

The trend across jurisdictions is clear: regulators and users increasingly expect organisations to say where they stand on accessibility, backed by real work. A statement is how you say it.

Honesty over overclaiming

The most important principle deserves its own emphasis: never overclaim. It is tempting to write "our site is fully accessible" or "100% WCAG compliant", but for any real, evolving site that is almost never true, and asserting it does real harm:

• It misleads disabled users, who trust the claim, encounter a barrier you said did not exist, and lose both time and trust.
• It can increase legal risk, because an inflated, demonstrably false claim can be used against you, whereas an honest statement showing genuine effort and a feedback route demonstrates good faith.
• It is a hallmark of the discredited accessibility-overlay marketing that disabled users and experts widely criticise — promising blanket compliance that the underlying site does not deliver.

The credible, safer and more useful approach is to state your target level, describe what conforms, list your known gaps honestly, and give people a real way to get help. Users respect candour; they do not respect a glossy claim that collapses on first contact.

A template outline

If you are drafting one, this outline (mirroring the sections above and the W3C model) gives you a complete skeleton:

1. Title and intro — "Accessibility statement for [site/organisation]".
2. Our commitment — a sincere sentence or two of intent.
3. Conformance status — standard, version, level (e.g. WCAG 2.2 AA) and honest status (fully / partially / non-conformant).
4. Known limitations — a frank, specific list with workarounds and, where possible, timelines.
5. Feedback and contact — how to report problems and request alternatives, with current contact details and a response commitment.
6. Technical details — supported browsers and assistive technologies; technologies the site relies on.
7. Assessment — how and when accessibility was evaluated.
8. Date — when the statement was prepared or last reviewed.
9. Legal/enforcement — escalation route where applicable.

Fill each section with real, tested information, publish the statement at a stable, easy-to-find URL (commonly linked from the footer), and review it whenever the site changes so it stays accurate.

Common mistakes

A few recurring errors undermine statements: overclaiming full compliance (the cardinal sin); using boilerplate that does not reflect your actual site or testing; omitting the feedback channel, which removes the statement's most useful function; letting contact details go stale so reports vanish; never updating the statement after redesigns, so it describes a site that no longer exists; and hiding known issues instead of listing them. Avoiding these comes down to the same discipline as the rest of accessibility: base the statement on real testing, keep it honest, and treat it as a living document.

The bottom line

An accessibility statement publicly declares your commitment, your conformance status against a stated standard and level (usually WCAG 2.2 AA), your known limitations, and a way for users to report barriers and get help — plus technical, assessment and legal details. The W3C/WAI Accessibility Statement Generator makes producing a complete one easy, and in places like the EU public sector a statement is legally required, with the European Accessibility Act pushing the same expectation wider. Above all, be honest: describe what truly conforms, list your real gaps, and never claim a perfection no live site achieves. Ground the underlying claims in real testing from how to run an accessibility audit and the standard in what WCAG is and the difference between A, AA and AAA.

Want an automated WCAG accessibility check to inform your statement, alongside SEO and performance? Analyse any URL with StackOptic — one report, free, no sign-up.