Accessibility statement Template

# Accessibility statement for [name of the site or app]

> Template version 1.0, 2026-10-07, from https://auricartisan.com/templates/accessibility-statement/
> Licence: CC0 1.0 (https://creativecommons.org/publicdomain/zero/1.0/). Copy it, change it and use it for anything; no credit needed.
> Replace everything in [square brackets], delete the parts that do not apply, then delete this note.
> If a law gives its own wording for your statement, such as the EU model statement for public sector bodies, use that wording and its order.

[Name of the organisation] wants everyone to be able to use [the site's address, or the app's name], whatever way they use the web. We aim for it to work:

- with a keyboard instead of a mouse or touch screen
- with screen readers, screen magnifiers and voice control
- when the page is zoomed, or shown at the width of a phone
- with the color, contrast and text settings of a browser or device

Licence: CC0 1.0 Universal, a public domain dedication. Copy, change and use these files for anything, including paid work, without asking or giving credit. The files are plain ASCII text in English, so they open the same everywhere.

1. Commitment. Who the statement is from, which site or app it covers, and that you want everyone to be able to use it.
2. Conformance status. Fully, partially or not conformant with a named version and level of WCAG, and the law that applies, if any.
3. Known problems. Each barrier you know about: what and where it is, the criterion it fails, who it affects, when it will be fixed, and how to get round it meanwhile.
4. Exempt content. Only content a law excludes, naming the law and the exemption.
5. Disproportionate burden. Only where a law allows the claim, after an assessment, with a review date and another way to get the information.
6. Measures. What you do to keep the site accessible: training, testing before release, regular audits.
7. Compatibility and technology. The browsers and assistive technology you tested with, and the technologies the site relies on.
8. How you tested. Your own evaluation or an external one, its date, its sample and, if you publish it, the report.
9. Feedback and complaints. How to report a barrier or ask for another format, how soon you reply, and where to go if the reply is not good enough.
10. Dates. When the statement was prepared and last reviewed, and who approved it.

W3C's generator also offers Not assessed, for content nobody has evaluated yet.

1. Audit first. A statement reports what an evaluation found, so start from one: your own, or an external audit. Use the audit report template
2. Check what your law asks for. Some laws require a statement, its content and even its wording; others ask for none. Accessibility laws in twenty jurisdictions
3. Fill in every bracket. Copy the known problems from your findings, in words a visitor understands, each with a fix date and a way round it.
4. Publish it where people look. Give it its own page and link to it from the footer of every page.
5. Keep it true. Review it after each audit and each large release, and at least once a year.

• Accessibility audit reportA report with a findings register, severity by user impact, results by criterion and retests, and a workbench to fill it in.
• Conformance reportA table of how a product meets each of the 55 WCAG 2.2 A and AA criteria, for buyers who ask a vendor for one.
• Accessibility lawWhat twenty jurisdictions ask for, and when
• WCAG 2.2Every success criterion, with live demos and tests