Accessibility statements: what they are and why every site should have one

An accessibility statement is a page on your site that says three things: that you build the site for people with disabilities, which standard you build it to, and how someone who hits a problem can reach you. It is one page, it is short, and the W3C, the body that writes the web's accessibility standard, publishes a guide to what goes in it.

What goes in one

The W3C's Web Accessibility Initiative lists the minimum (Source: W3C WAI, Developing an Accessibility Statement):

• "A commitment to accessibility for people with disabilities"
• "The accessibility standard applied, such as WCAG 2.2"
• "Contact information in case users encounter problems"

And the items it calls advisable:

• "Any known limitations, to avoid frustration of your users"
• "Measures taken by your organization to ensure accessibility"
• "Technical prerequisites, such as supported web browsers"
• "Environments in which the content has been tested to work"
• "References to applicable national or local laws and policies"

On where to put it: "Accessibility statements should be easy to find. Linking them from several places, such as from the footer, help menu, sitemap, about page, and other prominent areas helps users to find them" (Source: W3C WAI).

What "WCAG 2.2" means

The standard a statement names is the Web Content Accessibility Guidelines. The W3C publishes it to "explain how to make web content more accessible to people with disabilities," and there are three published versions, 2.0 from 2008, 2.1 from 2018, and 2.2 from October 2023, with the W3C encouraging the latest (Source: W3C WAI, WCAG 2 Overview). Each rule in it sits at one of three levels: "The success criteria are at three levels: A, AA, and AAA" (Source: W3C WAI). Our sites are built to WCAG 2.2 at level AA, and that is what our statements say.

Why every site, the small ones included

The W3C gives three reasons: to "show your users that you care about accessibility and about them," to give them "information about the accessibility of your content," and to "demonstrate commitment to accessibility, and to social responsibility" (Source: W3C WAI).

The plain version for a trade business: a customer with low vision who cannot read your phone number, or who cannot get past your contact form with a screen reader, needs a way to tell you. Without the statement there is no door. With it, there is an email address and a promise to fix what they found. Whether any law applies to your site is a question for a lawyer; the W3C lists legal references as optional content, and we leave that part to them.

The honest part: say only what you checked

The trap in an accessibility statement is the same as in any promise. It is easy to write "this site is tested at phone, tablet and desktop widths against WCAG 2.2 AA" and hard to make it true. We learned that on our own site: an early version of our statement claimed contrast testing and a tablet-width check that no command on our machine actually ran. The sentence read well and three of its claims had nothing behind them. We rewrote it to name the two checks that run before every release, and the rule we keep now is that a sentence may name a check only when there is a command that runs it, on every page the sentence covers.

Two more rules came out of that. The "last checked" date on the page moves only when the keyboard walkthrough is run again and recorded, never to the day the page was rebuilt. And automated tools are not the whole check: the maker of axe, the testing engine we run, says "you can find on average 57% of WCAG issues automatically" (Source: Deque, axe-core). The rest is a person with a keyboard, tabbing through every form and watching whether the focus stays visible.

Check yours from a phone

1. Scroll to your footer. Is there an Accessibility link?
2. Tap it. Does the page name a standard and a level, or does it only say "we are committed"?
3. Is there an email or phone for reporting a problem?
4. Is there a date, and does it say what was done on that date?
5. Does it admit anything? A statement with no known limitations is usually one nobody tested.

What we do on every build

Every site we build carries an accessibility page that names WCAG 2.2 AA, the two automated checks that run before each release, the date of the last recorded keyboard walkthrough, and the studio's contact for problems. The automated check runs on every page at seven screen widths and the site does not ship with a violation. It is included in every package, from Starter up. See what else is included at /build.