Free template + guide

How to write an accessibility statement — with a free template

An accessibility statement tells visitors what standard you're aiming for, how well you meet it today, and how to reach you if something's broken. Here's what to include, and a copy-paste template you can adapt and publish in minutes.

Jump to the template ↓
Or fill in a few fields with our free generator instead →

Transparency for real users

A screen-reader or keyboard user who hits a broken form knows it's a known, tracked issue with a real contact — not a site nobody's looking after.

Recognized good practice

Publishing a statement is a documented step under the EU Accessibility Act and W3C/WAI guidance, and widely treated as good-faith evidence under US law.

A living record, not a badge

Update it as your site changes. A statement is a snapshot of effort and current status — not a one-time certificate you publish and forget.

The basics

What an accessibility statement is — and isn't

An accessibility statement is a short, public page that tells visitors — and anyone reviewing your site for compliance — three things: what accessibility standard you're aiming for, how well you currently meet it, and how to reach you if something doesn't work. It usually lives at a predictable URL like /accessibility, linked from your footer next to your privacy policy and terms.

Why publish one at all? A few reasons keep coming up. Transparency: a screen-reader or keyboard user who hits a broken form or an unlabeled button benefits from knowing that's a known issue with a real person to report it to, rather than assuming the whole site is neglected. Good practice: the European Accessibility Act requires an accessibility statement for in-scope services, and W3C/WAI guidance recommends one regardless of jurisdiction. Documented effort: a dated statement naming your target standard, current status and a remediation plan is exactly the kind of record that matters if you ever receive an ADA demand letter or an EAA enforcement inquiry.

Honest note: a statement is not legal certification. No statement, however carefully worded, can certify that a site is legally compliant, and no honest tool — including ours — will tell you otherwise. Whether a site meets its legal obligations is ultimately a judgment for a court or regulator, informed by evidence like your statement, your scan history, and the fixes you've actually shipped. Treat the statement as documentation of your process, not a shield that makes the underlying work optional.
What to include

The six sections every good statement needs

A statement that's actually useful — to a visitor, and to anyone assessing your good-faith effort — covers six things. Skip any of them and the document reads as a formality rather than a real commitment.

  • Commitment statement — one or two sentences saying accessibility is a genuine, ongoing priority, not a one-time project.
  • Conformance target — the specific standard you're aiming for. WCAG 2.1 Level AA is still the most commonly referenced version in regulations and case law; WCAG 2.2 AA is the current version and the safer target going forward, since it's a superset of 2.1.
  • Assessment method — how you actually checked your site: automated scanning, manual testing, or both, and roughly when. This is the section most statements get vague about, and it's the easiest one to make concrete.
  • Known limitations — specific pages or components you know still fall short, in plain language, with a rough timeline for fixing them. Vague statements skip this; honest ones name it.
  • Feedback mechanism — a real, monitored contact (an email address, not just a generic contact form) for people to report barriers, plus a reasonable response-time expectation.
  • Date — when the statement was published and when it was last reviewed. An undated statement is close to worthless as evidence of anything.

Assessment method deserves a concrete example. Below is an actual Abledly scan report — the kind of dated, evidence-backed assessment you can point to in your own statement, instead of a vague "we tested this site."

abledly.com · scan report
Abledly scan report listing real WCAG issues with drafted code fixes

Click to enlarge
An actual Abledly scan report — the kind of dated assessment method you can name in your own statement.

Assessment method is the difference between "we believe this site is accessible" and "here's what we checked, when, and what we found." The second version is what actually holds up.

Quick check: does your current statement cover all six? Tick each one off against what you've already published.

  • Commitment statementA sentence or two saying accessibility is a genuine, ongoing priority.
  • Conformance targetNames a specific standard, e.g. WCAG 2.1 or 2.2 Level AA.
  • Assessment methodSays how and roughly when you checked — automated, manual, or both.
  • Known limitationsNames specific gaps in plain language, with a rough timeline.
  • Feedback / contactA real, monitored email — not just a generic contact form.
  • DateWhen it was published and when it was last reviewed.
Copy-paste

Accessibility statement template

Below is a generic template covering all six sections above. Replace the bracketed placeholders with your own details, adjust the standard and jurisdiction language to match your situation, and publish it as its own page rather than burying it in a PDF.

accessibility-statement.txt
ACCESSIBILITY STATEMENT FOR [ORGANIZATION NAME]

[Organization name] is committed to ensuring digital accessibility for people with disabilities. We are continually improving the user experience for everyone and applying the relevant accessibility standards.

CONFORMANCE TARGET
This statement applies to the website located at [website URL]. We aim to conform to the Web Content Accessibility Guidelines (WCAG) [2.1 / 2.2] Level AA[, and EN 301 549 if applicable in the EU].

CONFORMANCE STATUS
Based on our most recent review, we believe this website is [fully / partially / not yet] conformant with the standard above. [Partially conformant means some parts of the content do not yet fully meet the accessibility standard.]

ASSESSMENT METHOD
This website was assessed using [automated scanning tools / manual testing with assistive technology / both] on [assessment date].

KNOWN LIMITATIONS
[Describe any known accessibility barriers here and your plan to address them — for example: "Some documents published before 2024 may not be fully accessible. We are working to remediate these by [target date]."]

FEEDBACK
We welcome your feedback on the accessibility of [organization name]. Please contact us at [accessibility@example.com] if you encounter an accessibility barrier. We aim to respond within [X business days].

[EU only: if you are not satisfied with our response, you can escalate your complaint to the national enforcement body responsible for the European Accessibility Act in your country.]

This statement was last reviewed on [date].

---
This statement documents our accessibility effort and current status. It is not a guarantee or certification of full legal compliance.
Honest note: this is a generic starting point, not a legally reviewed document, and it won't tell you whether your conformance claim is actually true — that takes a real scan. If you'd rather fill in a few fields and get a formatted result instantly, use our free accessibility statement generator, which also produces country-specific EU versions with the correct national enforcement body.

This isn't just our opinion — publishing an accessibility statement is a documented good-practice step in wider accessibility guidance:

W3C
Publishing an accessibility statement is a recognized good-practice step for demonstrating conformance — the approach set out in W3C Web Accessibility Initiative (WAI) guidance on writing accessibility statements, and required as part of European Accessibility Act / EN 301 549 documentation for in-scope services.
Source: W3C Web Accessibility Initiative (WAI) — or generate yours free →
FAQ

Frequently asked questions

Is an accessibility statement legally required?

It depends on jurisdiction. Under the EU Accessibility Act and EN 301 549, publishing a statement is an explicit requirement for in-scope services. The US ADA doesn't mandate a specific statement format, but publishing one is widely treated as evidence of a documented, good-faith effort — the kind of record that matters if a demand letter arrives.

Should I target WCAG 2.1 or WCAG 2.2 AA?

WCAG 2.2 AA is the current version and the safer target going forward — it's a superset of 2.1 AA with a handful of added success criteria. Most existing regulations and case law still reference 2.1 AA by name, so naming both ("WCAG 2.1 AA, moving toward 2.2 AA") is a reasonable middle ground if you haven't fully assessed against 2.2 yet.

Does my statement have to say I'm 100% compliant?

No, and you shouldn't claim it unless you've actually verified it. "Partially conformant," with a clear list of known limitations and a remediation plan, is both more honest and, in practice, a stronger document than an unverified "fully conformant" claim that falls apart under scrutiny.

Where should I publish the statement?

Give it its own page, such as /accessibility, and link to it from your site's footer so it's easy to find from every page — the same way you'd link a privacy policy. Some jurisdictions also expect it linked from the homepage.

Does publishing a statement stop lawsuits?

No. It documents effort, it doesn't certify compliance, and it won't stop someone from filing a claim if your site genuinely has unresolved barriers. Pair the statement with a real scan and fixes — the statement is the paperwork, the scan and fixes are the substance.

Now check whether it's true

A statement documents intent. A scan tells you what's actually still broken. Run a free scan of your real site before you publish.

Run your free scan →