Writing an Accessibility Statement That Helps Instead of Hurting

An accessibility statement is a page almost every organization eventually publishes and almost nobody writes well. It is usually produced in an afternoon, copied from a template, and never revisited.

That matters more than it sounds, because of all the pages on your site, this is the one most likely to be read closely by a regulator, a procurement officer, or a lawyer deciding whether to send you a letter. It is a public, dated, signed claim about your own compliance. Most of them are wrong.

Why a bad statement is worse than no statement

A statement that overstates conformance is evidence against you.

Consider what it looks like to someone assessing your exposure. You published a page saying the site conforms to WCAG 2.1 Level AA. They opened it with a screen reader and could not submit the contact form. You have now documented, in your own words, a claim you cannot support — and demonstrated either that you did not test, or that you did and published the claim anyway. Neither reads well.

The same page with an honest statement — naming your standard, your last review date, and three things you know are not fixed yet — is a defensible position. It shows a programme in progress rather than a claim in dispute.

This is not a legal theory, and see the disclaimer at the end. It is what the two documents look like to a reader who is deciding whether you are a problem worth their time.

The template trap

Most statements are copied from a generator or another organization's site. The result is a page with an authoritative tone, a boilerplate conformance claim, and no relationship to the site it sits on.

The tells are consistent, and anyone who reads these regularly spots them instantly:

• A conformance claim with no testing described, so there is no way to know whether it is a finding or an aspiration.
• No date, or a date three years old, which tells the reader the programme stopped.
• A feedback address that turns out to be unmonitored — the single most common failure, and the one that turns a complaint into a filing.
• No known issues listed at all. Every site has some. A statement with zero named limitations is telling the reader that nobody looked hard.
• Reference to an overlay or accessibility widget as the accessibility measure, which now actively signals the opposite of what it is meant to.

What a real statement contains

The standard, with a version. "WCAG 2.1 Level AA" — not "we follow accessibility best practices," which means nothing and commits to nothing. If you are also covered by Section 508 or EN 301 549, say so.

An honest conformance level. WCAG defines three claims and the honest one is usually the middle:

• Fully conformant — meets every applicable criterion. Rare, and hard to defend without a published audit.
• Partially conformant — some content does not fully conform. This is the true answer for most organizations, and saying it costs you far less than you think.
• Non-conformant — the standard has not been met. Appropriate if you are early in a programme, and vastly better than a claim you cannot support.

What you tested, and how. Which pages or templates, which assistive technology, automated or manual, in-house or third party. A reader can then calibrate everything else on the page. This is also the section that distinguishes a statement from a press release.

Known limitations, named specifically. Not "some older content may not be fully accessible." That sentence appears on thousands of sites and conveys nothing. Say: agenda PDFs published before 2024 are not tagged; the third-party booking engine at this path has known keyboard issues we have raised with the vendor; video before this date lacks captions. Specific limitations demonstrate you looked. Vague ones demonstrate you did not.

A feedback route that a human monitors, with a response commitment you will actually meet. This is the most important line on the page and the most commonly broken. If somebody reports a barrier and hears nothing for three weeks, you have converted a person willing to help into a person with a documented complaint and evidence you ignored it. Two business days is a reasonable promise. Whatever you promise, route it somewhere monitored — not a general inbox.

An alternative way to get the thing done. If someone cannot complete a task online, what is the path? A phone number, an email, a counter. This matters both legally and practically: it is the difference between an inaccessible service and an inaccessible interface.

A date, and a review cadence. "Last reviewed" with a real date, and a commitment to a cycle you will keep. A statement that has not been touched in two years says the programme stopped.

What you are doing about it. One short paragraph on the remediation work in progress and roughly when. Not a promise of full conformance by a date nobody scoped — a description of a programme.

What to leave out

Conformance claims you have not verified. The whole argument of this page.

"We are committed to accessibility" as the opening line, with nothing after it. Every statement says this. It is the accessibility equivalent of "your call is important to us," and readers skip it looking for the part with information.

Mention of an overlay or widget as your accessibility measure. These do not produce conformance, are rejected by much of the disability community, and have been cited in accessibility litigation. Naming one in your statement tells a knowledgeable reader that nobody on the project knew that.

Legal hedging that undercuts the whole page. A statement written defensively enough reads as an admission with extra steps. If the lawyers need language in it, keep it at the bottom and keep the substance above it readable.

A skeleton you can actually use

Not a generator — a structure, with the reasoning attached. Replace every bracket with something true.

Accessibility at [Organization]

We want everyone to be able to use [site]. This page explains where we stand, what we know is not yet right, and how to tell us when something blocks you.

Standard. We are working towards WCAG 2.1 Level AA. [Add Section 508 or EN 301 549 if they apply to you.]

Current status. [Site] is partially conformant with WCAG 2.1 Level AA. Some content does not yet fully conform; the significant gaps are listed below.

How we tested. [Automated scanning across all templates, plus manual keyboard and screen reader testing of [these flows], using [NVDA on Windows / VoiceOver on macOS], carried out by [who] in [month, year].]

Known issues.

• [PDFs published before [date] are not tagged and are not readable by screen readers. We are converting the most-downloaded to HTML and expect that complete by [date].]
• [The [named] booking system is supplied by [vendor] and has known keyboard issues. We have raised these with them on [date]. In the meantime, you can book by calling [number].]
• [Video published before [date] does not have captions.]

Tell us about a problem. Email [monitored address] or call [number]. We aim to reply within two business days. If something on this site stops you doing what you came to do, we will help you do it another way while we fix it.

Last reviewed: [date]. We review this page every [six months] and after any significant change to the site.

The bracketed known issues are the part to spend time on. Three specific ones are worth more than a page of general commitments.

If you are a public body

Two additions. Under the ADA Title II web rule, state and local government entities are working to a fixed compliance date — April 2026 or April 2027 depending on population — and your statement is one of the few public artefacts a resident or a regulator will look at to judge whether a programme exists. Ours is covered in more detail on the Title II deadline page.

Name the alternative access route prominently rather than at the bottom. For a public body this is not a courtesy, it is program access: if a resident cannot pay a bill, apply for a permit or read an agenda online, there has to be a way for them to do it that does not depend on the website working for them.

Where to put it, and how to link it

In the footer of every page, with a plain link — "Accessibility," not an icon. At a predictable URL, conventionally /accessibility or /accessibility-statement.

And make sure the statement itself is accessible, which is a genuinely common and genuinely embarrassing failure. Real headings, sufficient contrast, keyboard-reachable contact links, and no PDF-only version.

Ours, as a worked example

We publish our own statement, and it names things that are not fixed. That is deliberate.

We are an accessibility firm — the temptation to claim full conformance is obvious, and it would be the wrong call. We ran our own checker across every page of this site and fixed everything it found, including a contrast failure on our own brand colour, navigation links below the minimum target size, heading-level skips across fifteen pages, and horizontal scrolling at 320px on eight. All of that is recorded publicly. What remains unresolved is named too.

Any vendor selling you this work should be willing to do the same, and asking them is a fast way to tell a practice from a product.

The short version

If you write only one thing today, make it this: replace whatever conformance claim your current statement makes with an accurate one, add a real date, and make sure the feedback address goes somewhere a human reads.

That takes an hour and moves you from a claim you cannot defend to a position you can. Everything else on this page is refinement.

---

This article is general information, not legal advice. Requirements vary by jurisdiction and by the obligations that apply to your organization — ADA, Section 508, Section 504, the European Accessibility Act and AODA all differ. If your statement is being written in response to a complaint or a procurement requirement, have counsel read it.