How to write an accessibility statement: what goes in, what to leave out

What a good one looks like

Here’s our own accessibility statement, the one for this website, cut down to five things you can copy.

Say the standard as an aim. We write We build the site to WCAG 2.2, at Level AA. And we close that part with This is our aim and what we check against, not a claim about every page.

Say what works as what a shopper can do. One of ours tells people Turn scripts off, and every page still shows its content.

List what doesn’t work yet, each with a way around it. The way around is for your shopper. Then add a next step for you: what you’ll do to fix it.

Here’s ours: With scripts off, the call page’s calendar and both forms do not work. Then the way around: If a form does not work for you, write to hello@evenentry.com with the same details it asks for. Last, our next step: We will test the spam check with a keyboard and a screen reader.

Say how it was tested, and what software misses. We say when we last checked. An automated checker went over every page. Next, our software went through every page by pressing keys, the way a keyboard user does. Then it went through again with a screen reader. A person signed off every check. Here’s what those two didn’t do: Neither check measured contrast.

Tell people how to reach you. We ask people to write about anything that got in their way, and we tell them what helps. We say: It helps to know the page, what you were trying to do and, if you are willing, what you use to browse. Then: We reply by email.

Four words to leave out

These four words sound reassuring. Each one promises more than a store can show. If you use one, have the proof ready.

compliant: WCAG doesn’t use the word. Its own example is an online store, where every page has to meet the level “from start to finish (checkout)”. If one step on the way to checkout falls short, WCAG says meeting the level for any of it “is not possible”.

certified: W3C’s page on the WCAG logos says “Claims are not verified by W3C.” Putting a logo up is a claim, and it’s yours to back up. W3C doesn’t vouch for anyone’s claims.

guaranteed: Every new product, app or theme edit changes your store’s pages. A guarantee promises it’ll all hold anyway.

fully accessible: A statement can’t promise more than the standard does. WCAG 2.2 says even content at its highest level, AAA, “will not be accessible to individuals with all types, degrees, or combinations of disability”. If a shopper reads fully accessible and then hits a barrier, we’d say they have fair reason to doubt the rest.

Why hold yourself to proof? In 2025, the US Federal Trade Commission issued an order about one overlay seller. An overlay is a script that changes web pages in each visitor’s browser, sold as a way to make them accessible. The order says the seller can’t claim its products keep sites up to WCAG without “competent and reliable evidence”.

That was about one seller’s ads for its own product, not a store’s pages. Still, we’d hold a store’s statement to the same bar. Our post on what overlays can and can’t fix has more.

When to update it

Put a date on it. W3C’s Accessibility Statement Generator asks for one, so people can tell if a statement is “actively maintained or outdated”. Ideally, it says, the date “should not exceed one year, or it may be considered unmaintained”.

A year is the longest to go. We’d update sooner:

• when a check finds a new problem
• when a check confirms a fix
• when you add an app, change your theme or redesign a page
• when you change how people reach you

One more habit, and it’s ours, not W3C’s. Our statement says Each time we change it, we date the change in the list below and keep the earlier version at its own address.