Accessibility Statement Generator

Create structured accessibility statement drafts based on WCAG 2.2 guidance. Import scan results instantly or build manually, then export to HTML, Markdown, PDF, or plain text.

WCAG 2.2 Structure
Multiple Export Formats
Free to Use

Statement generator capabilities

Step-by-Step Wizard

Guided 4-step process with optional scan import to collect everything needed for your statement

Multiple Formats

Export to HTML (ready to embed), Markdown, PDF, or plain text format

Template Options

Choose from basic, comprehensive, policy-focused, or developer-friendly templates

Accessibility statement workspace

Import from Recent Scan

Pull completed URL audit results into the draft, then verify scope, limitations, and claims before publishing.
Loading completed scans...

New to accessibility statements?

Load sample data to see how the generator works

1
2
3
4
Step 1 of 4

Organization & Contact Information

Basic information about your organization and how users can contact you

What Goes in an Accessibility Statement

A statement is only useful if a reader can work out three things from it: how accessible this thing actually is, what to do if they hit a barrier, and whether anyone is still maintaining it. Those map onto seven parts, all of which the generator above collects:

  1. Scope. Which sites, subdomains, apps, and documents this statement covers, and anything deliberately excluded.
  2. Standard and level. Normally WCAG 2.2 at Level AA, which is the level referenced by most laws and procurement rules.
  3. Conformance status. Fully, partially, or not conformant. See the wording section below.
  4. Known limitations. Named plainly, with what a user should do instead and, if you have one, a target fix date.
  5. Feedback route. A real email address or form, and the response time someone can expect. This is the part users actually need.
  6. How you assessed it. Self-assessment or third-party audit, which tools, and whether manual testing was involved.
  7. Date last reviewed. A stale date undermines everything above it.

Getting the Conformance Wording Right

The EU model statement defines three claims, and the vocabulary is worth borrowing wherever you are: fully conformant (meets the standard completely, no exceptions), partially conformant (most content conforms, some does not), and not conformant (largely does not meet the standard).

Almost every real site is partially conformant, and writing that down is the honest and defensible position. The temptation is to claim full conformance because it reads better, but a claim you cannot support is worse than an honest partial one: it is a statement in your own words, on your own site, that a complainant can quote back to you. Only claim full conformance if you have genuinely tested every page and pattern against every applicable criterion.

An automated scan does not support a full conformance claim

Automated tools catch only a portion of WCAG failures and cannot judge whether alt text is meaningful, whether focus order preserves meaning, or whether an error message helps. If your statement rests on a scan, describe it as a self-assessment using automated testing and avoid a full claim. The automated versus manual testing guide explains where the line falls.

Common Accessibility Statement Mistakes

  • Claiming full conformance on the strength of a scan. The single most common overclaim, and the easiest to disprove.
  • No contact route, or one nobody monitors. The feedback mechanism is the part with practical value to a user who is stuck. A dead address makes the statement decorative.
  • No date, or a date years old. Readers use it to judge whether anyone is still paying attention.
  • An empty limitations section. Every site has known gaps. Listing none reads as not having looked rather than as perfection.
  • Boilerplate with the standard left vague. “We are committed to accessibility” with no standard, level, or scope communicates nothing and cannot be checked.
  • A statement page that is itself inaccessible. It is the one page guaranteed to be read by people who will notice. Test it with a keyboard and a screen reader.

Frequently Asked Questions

What is an accessibility statement?

An accessibility statement is a public page explaining how accessible your website or app is and what you are doing about the parts that are not. A useful one names the standard you are measuring against (normally WCAG 2.2 at Level AA), states how far you currently conform, lists the known problems, explains how someone can report a barrier and what response they can expect, and records when it was last reviewed. It is a commitment and a contact route, not a compliance badge.

Am I legally required to publish an accessibility statement?

It depends entirely on where you operate and what kind of organisation you are, so treat this as orientation rather than legal advice. WCAG itself does not require you to publish a statement; conformance claims are optional under the standard. In the EU, the Web Accessibility Directive (2016/2102) does require public sector bodies to publish an accessibility statement, and Commission Implementing Decision 2018/1523 sets out a model for it. The European Accessibility Act extends accessibility obligations to many private sector products and services. In the United States, neither the ADA nor Section 508 requires a public statement in the way the EU directive does, though a statement is common good practice and is often requested during procurement. Check your own jurisdiction and sector.

What should an accessibility statement contain?

At minimum: the scope (which sites, apps, or documents it covers), the standard and level you are measuring against, your conformance status, the known limitations written plainly with what a user should do instead, a feedback mechanism with a real contact route and a response time, how the assessment was carried out (self-assessment or third-party audit), and the date it was last reviewed. If your jurisdiction requires an enforcement or escalation route, include that too. The generator on this page collects each of these in turn.

What conformance wording should I use?

The EU model statement uses three levels of claim and they are a good vocabulary to borrow even outside the EU. "Fully conformant" means the content meets the standard completely, with no exceptions. "Partially conformant" means most of the content conforms but some parts do not. "Not conformant" means the content largely does not meet the standard. Most real sites are partially conformant, and saying so is the honest and defensible position. Only claim full conformance if you have actually tested every page and pattern against every applicable criterion, because a false claim is worse than an honest partial one.

Can I claim full WCAG conformance based on an automated scan?

No. Automated tools reliably catch only a portion of WCAG failures, typically around a third, and they cannot judge things like whether alt text is meaningful, whether focus order preserves meaning, or whether an error message actually helps. A clean automated report tells you that you have no detectable violations of the rules the tool checks, not that you conform. If your statement rests only on a scan, say so in the assessment section: describe it as a self-assessment using automated testing, and avoid a full conformance claim. Pair the scan with manual keyboard and screen reader testing before making stronger claims.

How often should I update the statement?

Review it whenever the site changes materially and on a fixed schedule otherwise, with annually being a common minimum and every six months being better for actively developed products. The review date is part of the statement's credibility: a statement dated three years ago tells a reader that nobody is watching, even if the content happens to still be accurate. If a known limitation gets fixed, remove it and update the date rather than leaving a stale list.

What formats can I export?

You can export a draft as HTML that is ready to paste into a page, Markdown for a docs site or repository, plain text, or PDF. Whichever you choose, review the wording for accuracy before publishing, because the generator can only structure what you tell it. Then test the published page itself for accessibility: an accessibility statement that fails the standard it describes is a poor first impression, and it is the one page guaranteed to be read by people who will notice.

Is this tool free?

Yes, the accessibility statement generator is completely free, with no account or payment required. Nothing you enter is needed for it to work beyond producing your draft.

Essential Accessibility Resources

Comprehensive tools, checklists, and guides to help you create inclusive digital experiences

Top Pick

How to Write an Accessibility Statement

The three statement regimes kept straight: the mandatory PSBAR model format for UK public bodies, the EU Web Accessibility Directive model in Implementing Decision 2018/1523, and the EAA Annex V information duty for private companies that has no template. Plus what every good statement contains, the mistakes that create risk, and the free generator
accessibility statement
accessibility statement template
wcag statement
+1 more
View guide
Top Pick

VPAT & Accessibility Conformance Report Guide

VPAT and ACR demystified: the template versus the report, the four editions (508, EU, WCAG, INT) and who asks for each, how to read an ACR before buying, how to produce one that survives scrutiny with testing behind it, and why EAA-era European buyers ask for the EN 301 549 edition
vpat
vpat template
vpat en 301 549
View guide

WCAG Success Criteria Guides

In-depth guides to WCAG Level A and AA success criteria with interactive examples, testing methods, and implementation code
wcag
wcag 2.2
View guide

WCAG 2.2 Level AA Requirements

Complete list of every Level A and AA requirement for WCAG 2.2 conformance
wcag 2.2 aa
wcag conformance
View guide