What Should Go on Your Accessibility Statement Page?

What should an accessibility statement page actually say?

Three things at minimum. W3C's guidance is that a statement should contain a commitment to accessibility for people with disabilities, the accessibility standard applied such as WCAG 2.2, and contact information for users to report problems. Everything beyond that is useful, and those three are the floor.

Most B2B accessibility statements we read fail on the second and third. They open with a paragraph about how much the company cares, name no standard, and give no way to report a problem. That page does nothing for a disabled visitor and nothing for a procurement reviewer.

A good statement takes an afternoon and is genuinely useful to both. Here is the structure we use and where each part comes from.

Why publish one at all?

Because it is the only page on your site that tells a visitor what to expect and what to do when something breaks. Somebody using a screen reader who hits a form they cannot complete has two options: give up, or find a human. Your statement is how they find the human.

There is a commercial reason too. Accessibility questions now appear in B2B security and procurement reviews, and a dated, specific statement answers several of them before anyone asks. It sits naturally alongside the other assurance pages, which we cover in designing a trust center page.

And in some places it is required. W3C notes that "in some situations you may be required to provide particular content in your accessibility statements", pointing at the EU Web Accessibility Directive as an example. What applies to your organisation is a question for your own counsel, not for a blog post.

What does W3C advise beyond the minimum?

Five more things, and each one earns its place. W3C recommends including "any known limitations, to avoid frustration of your users", the "measures taken by your organization to ensure accessibility", "technical prerequisites, such as supported web browsers", the "environments in which the content has been tested to work", and "references to applicable national or local laws and policies".

The limitations line is the one that surprises people. Publishing your known problems feels like an admission. It is actually the most respectful thing on the page, because it saves a visitor from spending twenty minutes fighting something you already know is broken.

W3C also publishes a generator that walks through these sections and produces the markup. We use it as a checklist rather than a final output, because the wording it produces is generic and your wording should not be.

Which conformance status should you claim?

Whichever is true, and the terms are standardised so you do not have to invent language. W3C's generator offers four: fully conformant, meaning "the content fully conforms to the accessibility standard without any exceptions"; partially conformant, meaning "some parts of the content do not fully conform to the accessibility standard"; non conformant, meaning "the content does not conform the accessibility standard"; and not assessed, meaning "the content has not been evaluated or the evaluation results are not available".

Almost every real site is partially conformant. That is not a failure, it is the honest state of a site with a CMS, third-party embeds and a decade of content. Claiming full conformance on a large site is the claim most likely to be wrong.

The standard itself needs naming too. The generator lists WCAG 2.2 level AA, WCAG 2.1 level AA and WCAG 2.0 level AA as options. Level AA is the practical target, and W3C notes that level AAA conformance is not recommended as a general policy for entire sites.

What does WCAG conformance actually require?

More than passing an automated scan, and this is where statements quietly become inaccurate. WCAG 2.2 defines level AA as a page that "satisfies all the Level A and Level AA success criteria, or a Level AA conforming alternate version is provided".

The scope rule is strict. WCAG's second conformance requirement states that "conformance (and conformance level) is for full web page(s) only, and cannot be achieved if part of a web page is excluded", and each variation of a responsive page has to conform on its own.

There is also a process rule. Where a page is part of a series presenting a process, WCAG requires that all pages in that process conform at the specified level or better. A checkout or signup flow is only as conformant as its worst step. We unpack the criteria themselves in our guide to WCAG for B2B sites.

How do you write the limitations section honestly?

One entry per problem, with four parts. The generator's structure is a good template: which part of the content is affected, what the issue is, why it occurs, what you are doing about it, and what a visitor can do in the meantime.

That last part is the one to get right. "We are working on it" helps nobody today. "This table is not readable by screen readers; email us at this address and we will send the same data as a plain text summary" is a real workaround.

WCAG also gives you legitimate cover for content you do not control. It states that "if the page does not conform to WCAG only for reasons that are legitimately outside the author's control then the author can make a claim of partial conformance", which is aimed at third-party content you cannot monitor or repair. Say which embeds those are.

What technical information belongs on the page?

What you built with and what you tested on. The generator asks for the technologies the content relies on, with HTML, WAI-ARIA, CSS, JavaScript and SMIL as the listed options, plus room for anything else.

Then compatibility. List the environments the content has been tested to work in, and separately list known incompatibilities. A visitor on an older screen reader and browser pairing deserves to know before they start, not after.

State your assessment approach as well. The generator distinguishes self-evaluation, where "the content was evaluated by your own organization", from external evaluation, where "the content was evaluated by an external entity". Both are valid. Saying which one you did is what makes the claim readable.

Who approves it, and what about complaints?

Name a person or a department, and give their function. The generator has fields for exactly this, and it changes the character of the page: a statement with a named owner reads as a commitment, while an unsigned one reads as boilerplate.

Include a response time. The generator asks for the typical duration for a response to feedback, and publishing that number is what turns a contact address into a promise. Pick a number you can keep.

Then a formal complaints path for anyone not satisfied by the feedback mechanism. In regulated contexts this may be prescribed. Elsewhere, an escalation route to a named senior owner is enough, and it is better than nothing by a wide margin.

Where should the page live and how often should it change?

Linked from the footer of every page, at a stable URL, with a visible publication date. The generator includes a date field for good reason: an undated accessibility statement is unverifiable, and a statement dated three years ago is worse than none because it proves nobody is watching.

We set a review cadence of twice a year plus any major redesign or new template. The review is short: re-run the automated checks, retest the key flows, update the limitations list, change the date. Automated testing does most of the heavy lifting here, and we described how we wire it up in automated accessibility testing.

If the limitations list has not changed in a year, either nobody is fixing things or nobody is looking. Both are worth knowing.

What does a good statement signal to a B2B buyer?

That your team measures things and tells the truth about them. A specific, dated, partially conformant statement with a real limitations list and a named owner reads as competence. A glowing, vague, undated one reads as marketing, and procurement teams read hundreds of both.

That is the part we would emphasise to any founder weighing whether this page is worth the afternoon. It is one of the few pages where honesty is the more persuasive option, because the audience is trained to spot the alternative.

If you want us to write one against your actual test results rather than a template, that is a small piece of work we do often. Start a conversation at phoenix.studio.