Accessibility statement: what to include, with examples

An accessibility statement describes, in plain language, how accessible your website, app or other digital content is. The W3C Web Accessibility Initiative's guidance on accessibility statements says its main audience is the people who use the site, so it recommends everyday wording over developer or legal jargon. This guide covers who has to publish one, what to put in it, example wording and how to keep it accurate.

A statement describes your site. It does not make the site accessible, and it is not a certificate. Treat it as a public claim about your own testing, and write only what you have tested.

Who must publish an accessibility statement

The duty depends on who you are and where you operate. The table below lists the statement duties we have verified against primary sources. Anything not in the table is not covered by this guide.

For the wider picture, see our pages on EU accessibility law, UK law, Canada and the European Accessibility Act. Penalties and enforcement vary, and several of these duties sit alongside others in the same law.

United States

We know of no US federal statute that requires a business to publish an accessibility statement. ADA Title III has no web regulation, and the DOJ's web guidance of March 18, 2022, which is non-binding, calls WCAG "helpful guidance". A statement is therefore usually a voluntary document in the US, and a public claim all the same. The FTC's April 2025 final order against accessiBe ($1,000,000) concerned representations that a product would make a site WCAG-compliant, which the FTC charged as false or unsubstantiated. Our ADA website guide and Title II deadline guide cover the US rules, and state and local government sites face the Title II web rule on April 26, 2027 or April 26, 2028, depending on population.

What to include in an accessibility statement

W3C's guidance sets a minimum of three things: a commitment to accessibility for people with disabilities, the accessibility standard you applied (its example is WCAG 2.2), and contact information for reporting problems. It advises adding known limitations, the measures you take, technical prerequisites such as supported browsers, the environments you tested in, and the laws and policies that apply. In practice, a useful statement has these parts:

1. Commitment. One or two sentences on what you aim for and who it is for.
2. Standard and version. Name it exactly, for example "WCAG 2.2 Level AA". Our WCAG version guide helps you pick; EN 301 549 is the reference for EU rules.
3. Conformance status. Say whether the site fully, partly or does not meet that standard, and choose "fully" only after real testing of every criterion at that level. Partly is the accurate answer for most sites.
4. Known limitations in plain words. Say what does not work, where, and what you are doing about it. W3C's own example contrasts citing a success criterion with the plain statement "videos do not have captions".
5. Alternatives. How a visitor can get the information another way: a phone number, an email address, a transcript.
6. How to report a barrier. A monitored email address or form, what to include (page address, browser, assistive technology), and the time in which you will reply. Promise only a time you can keep.
7. How you assessed the site. Self-evaluation or an outside audit, the tools used, whether people tested with a keyboard and screen reader, and when.
8. Technical prerequisites and supported environments. Browsers and assistive technologies you tested with.
9. Dates. When you published it, when you last reviewed it and when the next review is due.
10. Legal references, if any apply. The law that requires the statement, and any complaint or enforcement route the law names.

W3C also offers a statement generator. Ours, the accessibility statement generator, drafts the common case in the browser: one organization, one site and a short list of known issues, and nothing you type is sent anywhere. Add anything your law requires that the draft does not cover, such as extra contact routes or a complaints procedure.

You can see these parts in use in GotAlt's own accessibility statement: a commitment, the standard, a conformance status, a list of known issues, how we test, how reports are handled, a feedback address and a date.

Example wording

Replace everything in square brackets, delete anything that does not apply, and do not publish a status you have not tested for. Do not write "fully meets" unless every criterion at that level has been tested. This example is written for a site that has been tested and has known gaps:

Accessibility at [Organization]

We want everyone to be able to use [website address]. We aim to meet WCAG 2.2 Level AA.

Where we stand. In [month and year] we tested [the pages or journeys covered] with [automated scans and manual testing using a keyboard and a screen reader]. [Choose one after testing: This website partly meets WCAG 2.2 Level AA. / This website does not yet meet WCAG 2.2 Level AA.] Some content does not yet meet it.

What does not work yet. [The videos on the training page do not have captions.] [The size filter on the product list cannot be used with a keyboard.] [We plan to fix these by month and year.]

Other ways to get the information. [Call us on number or email address and we will send the information in another format.]

Tell us about a problem. If you find a barrier, email [address] with the page address and, if you can, the browser and assistive technology you were using. We reply within [number] working days.

This statement was published on [date] and last reviewed on [date]. We review it [every number months] and after major changes to the site.

A shorter example for a small site

A small site with a short list of known issues can use a shorter version. The same rule applies: write only what you have tested.

Accessibility

We aim for [website address] to meet WCAG 2.2 Level AA. We last checked [the pages or journeys covered] in [month and year]. [Known problem in plain words.] If something on the site does not work for you, email [address] and we will help or send the information another way.

Published [date]. Last reviewed [date].

Wording to avoid

• Never write "fully accessible", "WCAG compliant", "ADA compliant" or "100% accessible". No scan can show this, and the FTC order described above concerns exactly this class of claim. Describe what you tested instead.
• Seals and badges that imply an independent audit, unless one really took place and the statement says who carried it out and when.
• A commitment with nothing behind it. "We care deeply about accessibility" with no standard, no known issues and no contact is a statement in name only.
• An unnamed standard. "Industry standards" tells a visitor nothing; name the version and level.
• Jargon. "Fails 1.2.2" is for your audit report. The statement should say "videos do not have captions".

Real statements to read

Reading finished statements shows how the parts fit together. These are the sources we have checked:

• W3C's minimal example and complete example, both created with W3C's generator, show the smallest and fullest versions of the same structure.
• The accessibility statement of the W3C Web Accessibility Initiative website is a statement from the organization that publishes the standard.
• GOV.UK's sample accessibility statement is sample wording for UK public sector bodies, based on the model statement. Some of its wording is legally required.
• GotAlt's own accessibility statement shows the parts above applied to a product site.

A statement is not a VPAT or an ACR

You may be asked for a VPAT (Voluntary Product Accessibility Template) or its completed form, an Accessibility Conformance Report (ACR). The Information Technology Industry Council, which publishes the template, describes the ACR as a reporting format for buyers and sellers of information and communications technology. It is a different document from a statement: a statement is a public summary for visitors to your site, while an ACR is a VPAT filled in with documented testing results, written for a buyer. One does not replace the other.

Where to put it

Publish the statement as an ordinary web page, not a downloadable file, so that it is itself accessible. W3C advises linking to it from prominent places such as the footer, help menu, sitemap or about page, with the same link name everywhere. GOV.UK gives the same advice for websites: an HTML page linked from every page, ideally in the footer. For mobile apps, make the statement available in the app store, on a website or both. If you run several related websites or apps, use the same link name across all of them.

How to keep it current

An out-of-date statement misleads the people it is meant to help. A routine that works:

• Put dates on it and keep a change log. We recommend a published date, a last-reviewed date and a short list of changes, so visitors can see the statement is maintained.
• Review it at least once a year. That is GOV.UK's expectation for UK public bodies and Canada's 12-month update rule for organizations with a statement duty, and a sensible default for everyone else.
• Update it after changes that touch the experience. A redesign, a new checkout, a new theme or platform, a new plugin or a new video library can each add or remove limitations.
• Test before you edit. Re-run the free scan, the bookmarklet on key pages, and a keyboard and screen reader pass before changing the conformance status. A deep audit opens up to six images per page to check that the alt text is true. Our methodology page lists what each check can and cannot see.
• Remove fixed items and add new ones. A known-issues list that only grows, or never changes, suggests no one is looking at it.
• Answer what comes in. Someone has to own the feedback address, and reports are evidence of what to fix next. If you want pages re-checked every week without remembering to, paid plans re-check your monitored pages every week.

Automated tools cover only part of WCAG, and any status you publish rests on testing by people as well. Our guide to testing website accessibility sets out how, and how to make a website accessible covers the fixes that make a better statement possible. For the fixes people most often need, see the most common accessibility errors, alt text and color contrast.