My Tool Studio
WCAG & Accessibility·3 min read

What Goes in an Accessibility Statement (W3C Style)

A public promise, in writing, on your own domain: that's what an accessibility statement amounts to, and it's why the wording deserves more care than a boilerplate paste. Knowing what goes in an accessibility statement keeps the document honest and useful at once: the standard you target, how far you've gotten, the gaps you know about, and a working way for someone blocked by a barrier to tell you. Regulators in Ontario and the EU expect one, and US lawyers treat one as baseline good-faith evidence.

Open the toolAll insights
87A11Y SCOREAAA7.1:1

What goes in an accessibility statement, section by section

The W3C structure.

The W3C's recommended format, the one regulators and opposing counsel both recognize, runs in a fixed order: a commitment paragraph naming your organization, a list of measures you take to support accessibility, a conformance status against WCAG 2.1 Level AA, known limitations if any exist, a feedback section with contact channels, your assessment approach, and the date the statement was created.

None of it is decoration. The measures show process, the status makes a falsifiable claim, the limitations preempt surprise, and the feedback channel is the part a blocked user actually needs. A statement missing any one of these reads as incomplete to anyone who reviews them professionally.

Conformance status wording in a WCAG statement

Three options, one honest default.

The conformance status wording carries the legal weight, so the generator constrains it to three W3C-aligned formulations. Fully conformant asserts the content meets WCAG 2.1 AA without exception, a claim you should only publish after automated and manual testing both agree. Partially conformant states that some parts don't fully conform, which is accurate for the overwhelming majority of real sites. Working toward conformance signals active remediation that hasn't reached the bar yet.

Partial conformance plus a candid limitations list is the strong position, not the weak one. Overclaiming is what gets statements quoted back at their authors.

A worked accessibility statement, generated line by line

Form in, document out.

Feed the generator a bookshop: Input: organization "Maple & Main Books", website "mapleandmain.ca", status partially conformant, contact access@mapleandmain.ca, and one known limitation, "Older PDF reports are not yet tagged for screen readers". The preview assembles the full document instantly, and the conformance section reads: Output: "mapleandmain.ca is partially conformant with WCAG 2.1 level AA. Partially conformant means that some parts of the content do not fully conform to the accessibility standard."

The limitation becomes a bullet under Known limitations, the email lands in the Feedback section beside a five-business-day response promise, and the closing line records the creation date. Copy it as Markdown or download the HTML and the job is done before the meeting ends.

Where to publish the statement so people find it

Predictability is the feature.

Convention has settled the where to publish the statement question: a stable path like /accessibility/, linked from the footer of every page, in the same neighborhood as your privacy policy. Screen reader users and auditors both check the footer first, so novelty placement only hides the document from the people it exists for.

The HTML download comes unstyled on purpose, plain headings, paragraphs, and lists, so it inherits your site's CSS the moment you drop it into a CMS page. One irony worth avoiding: don't let the statement page itself fail contrast or heading structure.

Accessibility statement mistakes that backfire

A bad statement is worse than none, because it's quotable. The recurring failures:

  • Claiming full conformance without testing to back it. Any user who hits a barrier now has your own words as an exhibit.
  • Leaving known limitations empty while the scanner report lists forty issues. Candor there is what makes the rest credible.
  • Publishing a feedback address nobody monitors. An ignored barrier report is more damaging than an unreported one.
  • Setting a creation date once and never revisiting it. A statement dated three redesigns ago announces neglect.

Keeping your accessibility statement honest over time

It's a living document.

Three maintenance habits keep the promise true. Regenerate the statement after each major remediation round, updating the status and pruning limitations that no longer exist. Source the limitations list from your latest scan results rather than from memory, so the document tracks reality. And only keep the five-business-day response line if someone actually owns that inbox; edit the copy after download if your real turnaround differs.

Tools that feed a stronger accessibility statement

Evidence before assertion.

The statement should be the last document you produce, not the first. Run the WCAG Accessibility Scanner to ground your conformance claim and harvest the known limitations list from its findings. Track the human-verified criteria in the WCAG Compliance Checklist so the assessment approach section reflects genuine review. Ontario organizations will find the statement satisfies expectations tracked in the AODA Compliance Checklist, and US public entities can pair it with the ADA Title II Checker, whose readiness steps explicitly include publishing one.

Try it now

Open Accessibility Statement Generator

The tool is one click away. No sign up, no upload, no payment.

Open Accessibility Statement Generator