Guide

Website Accessibility Statement: What to Put in It, and a Template You Can Copy

Most templates for this search are a Word file behind a form, or a legal-sounding page you are meant to paste and forget. The W3C's own guidance asks for something simpler and more honest: a short page that tells real visitors what works, what does not, and who to contact. This guide builds that page field by field, shows who is required to publish one, and says plainly what a statement cannot do. Checked 1 November 2026. General information, not legal advice.

Website Accessibility Statement: What to Put in It, and a Template You Can Copy

Key takeaways

  • A statement is a page for your visitors, not a shield. The W3C Web Accessibility Initiative says its main readers are people who hit a problem on your site and want to know what to do next.
  • Three parts are the minimum. The W3C page lists a commitment to accessibility, the standard you work to (for example WCAG 2.2), and a way to report problems.
  • Add the honest parts. Known limits, what you do about them, and the date you last checked make the page useful and believable.
  • Who must publish one depends on where you are and what you are. In the UK, public sector sites must. The US Department of Justice web guidance we read does not mention statements at all.
  • Never claim more than you have checked. "Fully compliant" is a claim about your whole site. If nobody has tested it, say "we aim to" and list what you know.

This guide is general information and not legal advice. For what the law asks of your business, ask a qualified adviser and read the official pages linked below.

The short answer

An accessibility statement is a short page, linked from every page, that says three things in plain words: you care that people with disabilities can use the site, which standard you work to and how far you have got, and how to tell you when something does not work. Write it for the visitor who is stuck. Keep legal and technical language for a linked report, if you have one.

What the official guidance asks for

We read the W3C Web Accessibility Initiative page "Developing an Accessibility Statement" on 1 November 2026. It was first published in November 2018 and updated on 11 March 2021. It separates what to include into two groups.

GroupWhat the W3C page lists
MinimumA commitment to accessibility for people with disabilities; the accessibility standard you apply, such as WCAG 2.2; contact details for reporting problems
Advisable extrasKnown limitations; the measures your organisation takes; technical prerequisites such as supported browsers; the environments you tested in; references to laws and policies that apply

On tone, the page says technical and jurisdictional language is likely to cause confusion. It suggests you describe a limit in everyday terms, such as "some videos have no captions", instead of quoting a WCAG criterion number. It also suggests linking the statement from places people look when stuck, such as the footer, a help menu, the sitemap and the about page, and using the same link name across the site.

The W3C also offers a free generator. We opened it on 1 November 2026. It walks you through basic details, your efforts, technical information, and approval and complaints. It says none of the fields are required and nothing you type is stored outside your browser, and you can download the result as an HTML page.

A statement you can copy, field by field

Below is a plain version built on the same parts. Replace everything in square brackets. Delete any line you cannot honestly stand behind. A shorter true page beats a longer hopeful one.

Accessibility statement for [Business name] We want everyone to be able to use [website address], including people who use screen readers, keyboards, voice control or magnification, and people with low vision, hearing loss, or learning and attention needs. The standard we work to. We aim to meet WCAG [2.2 or 2.1] Level AA. Where we are today. [Choose one: We have checked [the whole site / these pages: list] and believe they meet the standard. / We have checked [these pages] and found some problems, listed below. / We have not yet had the site formally checked, and we are fixing problems as we find them.] Known problems. - [Plain description, for example: Videos on the [page name] page do not have captions yet.] - [Plain description, for example: The booking calendar cannot be used with a keyboard alone.] What you can do instead. For any of the above, email [address] or call [number] and we will [give you the same information another way / book for you / send you the document in a format you can read] within [number] working days. Tell us about a problem. If something on this site does not work for you, contact [name or role] at [email] or [phone]. Please tell us the page, what you were trying to do, and the device or assistive tool you use if you are happy to share it. We reply within [number] working days. How we checked. [Our team reviewed the site on [date] using [keyboard only / a screen reader name / browser names]. / An outside specialist reviewed the site on [date].] We last updated this statement on [date].

That follows the W3C structure: a commitment, a standard, a contact route, and the extras of known limits, an alternative route and the date.

How to fill in each part honestly

The template is easy to copy and easy to get wrong. Name one WCAG version and level you are really working to; the W3C generator offers 2.2, 2.1 or 2.0 at Level AA. Pick the "where we are today" sentence that matches what has been checked, by whom and when, and never write "fully accessible" with no test behind it. List known problems in everyday words rather than hiding them. Offer an alternative you will honour, and give a named role and an inbox that is read. A scanner finds some issues, such as low colour contrast, but cannot judge whether a page makes sense to someone using a screen reader. Treat its score as a starting point.

Do you have to publish one?

It depends on the country and on what kind of organisation you are. We read three official pages on 1 November 2026.

WhereWhat the official page saysSource
UK, public sectorPublic sector websites and mobile apps must meet accessibility standards and publish an accessibility statement under the 2018 regulations. The statement must say whether the site is fully, partly or not compliant, which parts fall short and why, how to get alternatives, and how to report problems and complain. The page says to review it after major changes and at least once a year, and links a sample statementGOV.UK guidance, last updated 27 September 2024
US, businesses open to the publicThe Department of Justice web guidance says the ADA's nondiscrimination duties apply to goods and services offered on the web. It names WCAG and the Section 508 Standards as helpful guidance, says it sets no detailed web standard, suggests a way for the public to report problems, and does not mention accessibility statementsADA.gov web guidance, dated 18 March 2022
US, state and local governmentThe Department of Justice fact sheet sets WCAG 2.1 Level AA for web content and apps, with compliance dates of 26 April 2027 for governments serving 50,000 people or more and 26 April 2028 for smaller ones, as extended by a rule it dates 20 April 2026. It does not mention statementsADA.gov web rule fact sheet, dated 8 April 2024

The W3C page adds that some organisations must provide a statement, such as public bodies in countries that follow the EU Web Accessibility Directive, and points to its own list of laws and policies by country. We could not load the European Commission page on the European Accessibility Act today, so we say nothing about its detail. If you sell to people in the EU, ask an adviser.

For a small private business in the US, none of the pages we read says you must publish a statement. The law still expects your site to be usable by people with disabilities, so a statement is a good way to give them a route to tell you when it is not. It does not replace fixing the site.

Where to put the page and what to call it

Call it "Accessibility statement", put it at a short address such as /accessibility, and link it from the footer of every page. Add links from the help menu and your contact page, as the W3C suggests. Our guide to what to put on a contact page covers that page. Check the statement page itself with a keyboard, since an inaccessible statement defeats its purpose. You can test colours with our colour contrast checker.

A 30 minute check before you write a word

If you have not looked at your site with accessibility in mind, do this first. It is not an audit, but it gives you true things to write.

  1. Tab through the home page with only Tab and Enter. Can you reach the menu, the contact button and the form, and see where you are?
  2. Zoom to 200 percent. Does the text stay readable, with nothing cut off?
  3. Check one form. Does every field have a visible label, and do errors say what went wrong?
  4. Check images and video. Do meaningful pictures have a short text description? Do videos have captions?

Whatever fails goes onto the known problems list or the fix list. Our website audit checklist for small business puts this check next to speed, search and conversion checks.

When a statement is not the right move yet

Fix the site first if nothing has been checked, if a major problem is known and easy to fix, or if you are about to rebuild. Write the statement from the real state of the site, never from another business's wording. Our guides to therapist website design, lawyer website design, dentist website design and nonprofit website design note where the people you serve may need more from a site.

Keeping it true

A statement goes stale like a price list does. Review it at least once a year, which is what GOV.UK asks of public sector sites, after any redesign, and whenever you fix something on the known problems list. Change the date each time. Ongoing care belongs in your maintenance plan; see what website maintenance costs on Webflow, WordPress and Shopify. If you also serve UK customers, our UK website guide covers other pages that country expects.

How we help at Amariq

We build and look after sites on Webflow, Framer, WordPress and Shopify, and also on Wix, Squarespace and custom builds. For accessibility we start from the parts a statement depends on: keyboard use, heading order, colour contrast, form labels, link text and captions. We fix what we find in the build, then write down what remains in everyday words, so the statement matches the site.See our web design service and our website optimisation service.

Frequently asked questions

Is an accessibility statement required by law?

It depends on who you are and where. In the UK, public sector websites and apps must publish one under the 2018 regulations, according to GOV.UK. The US Department of Justice web guidance we read does not mention statements. Ask a qualified adviser about your own case.

Does having a statement protect me from a lawsuit?

We found no official page saying so. The Department of Justice guidance does not mention statements, and a statement does not fix a site. It does give visitors a route to tell you about a problem, which is a practice the guidance suggests. This is not legal advice.

Can I just paste a template?

You can start from one, but edit every line. The accessible.org template page itself says its template needs to be reviewed and edited before use. A statement that claims things you have not checked can do more harm than having no page.

Which WCAG version should I name?

Name the version and level you are really working to. The W3C generator offers WCAG 2.2, 2.1 and 2.0 at Level AA. GOV.UK sets WCAG 2.2 AA for UK public sector sites, and the US state and local government rule uses WCAG 2.1 Level AA. If you have no obligation, 2.2 AA is a sensible target.

In the footer of every page, with the same name each time. The W3C also suggests the help menu, the sitemap and the about page.

What if my site has known problems?

Say so, in everyday words, and say what visitors can do instead. The W3C lists known limitations among its advisable additions. Listing a problem is more useful to a visitor than leaving it out, and it gives you a to do list.

How often should I update it?

At least once a year and after any major change. GOV.UK asks that of public sector sites. Update the date each time so a reader can see that it is current.

Rahat Khondokar, founder of Amariq

Rahat Khondokar

Founder & CEO, Amariq

Rahat designs and builds websites for marketing teams and ecommerce brands, and writes here about the structure, copy and conversion work behind them. More about Amariq. Find him on YouTube, Dribbble and LinkedIn.

Keep reading

Related articles.

All articles