How to Write an Accessibility Statement (With an Example)

By Andrew Szigety, DHS Trusted Tester (TT‑2606‑09221). Published October 14, 2026.

An accessibility statement is a short public page that tells people how accessible your website or app is. A good one names the standard and version you test against, says whether you fully or partly meet it, lists known problems in plain words with a date, says how you checked, and gives a contact who replies within a stated time. The W3C has a free generator for it. Checked on October 14, 2026.

What a Statement Is For

The W3C’s guide, Developing an Accessibility Statement, says statements are mainly for the people who use your content, and that they usually read one when they’ve hit a problem. So it should be in plain language, not the language of developers and lawyers. Its example: say “videos do not have captions,” not “WCAG Success Criterion 1.2.2 was not met.”

The same page says statements aren’t technical assessments or declarations of conformity, though they should point to one to back up what they say. That’s the split between a statement and an ACR, covered further down.

What to Put in It

The W3C lists three things every statement should have: a commitment to accessibility for people with disabilities, the standard you apply, and contact details for people who run into problems. It also advises known limitations, the measures you take, supported browsers and assistive technology, the environments you tested in, and the laws that apply. In practice, a statement people can use covers these:

• A commitment. One or two sentences on who the product should work for. Skip the mission-statement tone.
• The standard and its version. “WCAG 2.2 Level AA,” not “WCAG” or “the ADA.” The version matters, and WCAG 2.1 vs 2.2 explains the difference.
• The conformance status. The W3C generator offers four: fully conformant, partially conformant, non conformant, and not assessed. Pick the one your testing supports.
• Known limitations, with a date. What doesn’t work, in everyday words, what to do in the meantime, and when you expect a fix if you have a plan. The generator has fields for each.
• How you checked. The generator’s options are self-evaluation and external evaluation, and it suggests linking an evaluation report or other evidence.
• A feedback route and a response time. An email address at minimum, ideally more than one way to reach you, and how long a reply usually takes.
• The date. The generator says a statement older than about a year may look unmaintained, and suggests writing the month out so the date reads the same everywhere.

The W3C generator builds the page from a form, stores nothing outside your browser, and lets you download the result as HTML to edit and brand. None of its fields are required, so it’s on you to fill in the ones that matter. Link the finished statement from your footer and use the same link name everywhere, as the W3C suggests.

An Example Accessibility Statement

Here’s a short statement for a made-up scheduling app, ExampleApp, from a made-up company, Example Inc. It reports partial conformance honestly and gives a workaround for each known problem.

Every limitation is dated, written in terms a user would notice, and paired with a way around it. The status matches the list: an app with three open problems isn’t fully conformant, and the statement doesn’t pretend otherwise. The full detail sits in the ACR, and the statement points to it.

Accessibility Statement vs VPAT (ACR)

The two get mixed up because both describe accessibility. They answer different people.

A statement doesn’t answer a request for a VPAT, and an ACR is too technical to be the page a user finds when a form won’t submit. Most software companies selling to enterprises or government need both, and the statement can link to the ACR or offer it on request. VPAT vs ACR explains how the template and the finished report relate, and how to fill out a VPAT walks through the form. A full sample VPAT/ACR shows what the report side looks like.

Where a Statement Is Required

EU public sector bodies. Directive (EU) 2016/2102, Article 7, requires public sector bodies to publish and regularly update an accessibility statement for their websites and mobile apps, using the model the Commission set in Implementing Decision (EU) 2018/1523. It has to explain what isn’t accessible and why, with alternatives where appropriate, link to a feedback mechanism, and link to the national enforcement procedure. The model says to choose “fully compliant” only when every requirement is met without exceptions, to state how the statement was prepared (a self-assessment or a third-party assessment, for example), and recommends reviewing it at least once a year. Public service broadcasters and some NGOs are outside the directive.

The European Accessibility Act. The EAA, Directive (EU) 2019/882, doesn’t use the phrase “accessibility statement.” For the consumer services it covers, such as e-commerce, consumer banking, e-books and electronic communications, Article 13 and Annex V require the provider to publish information on how the service meets the accessibility requirements, in its general terms and conditions or an equivalent document, in a form people with disabilities can use. Many providers publish that as an accessibility statement. Microenterprises providing services are exempt from the service requirements, and each country’s own law sets the details. The EAA page covers who it reaches.

US state and local government. The Department of Justice’s 2024 ADA Title II web rule requires WCAG 2.1 Level AA but doesn’t require an accessibility statement. In the rule’s explanation, the Department encourages public entities to provide one that tells people how to report problems, cites the W3C guide, and declines to require specific policies such as statements.

Outside those cases a statement is usually voluntary, but buyers notice it. The HECVAT that colleges send vendors asks for a link to your accessibility statement or VPAT. This is a summary of the rules, not legal advice, so check your own situation with counsel.

Common Mistakes

• Claiming full compliance without testing. “Fully compliant” is a claim about every requirement of the standard. If nobody tested the site, the honest status is “not assessed,” which is one of the W3C’s four options.
• Pasting an overlay vendor’s boilerplate. A statement that credits an overlay widget for the site’s accessibility describes the widget, not the site, whose code hasn’t changed. The article on overlays covers why that claim doesn’t hold.
• No way to report a problem, or one nobody reads. The contact route is the part users need most. Give a real address, say who answers it and how fast.
• No date, or an old one. An undated statement can’t be trusted, and a dated one from three releases ago describes a different product.
• A law instead of a standard. “ADA compliant” names a law, not something you can test against. Name the WCAG version and level.
• Jargon. A list of failed success criteria numbers tells a user nothing. Describe what they’ll notice and how to get around it.

Each row was read from the page it links to on October 14, 2026. The W3C guide was last updated March 11, 2021, and its generator May 20, 2025. Member states set the details of both EU directives in national law.

How Harbor Does It

An honest statement is built from audit findings: the standard, the status, the known limitations and the date all come from testing. Harbor tests every unique template by hand against all 55 WCAG 2.2 Level A and AA criteria, with a keyboard and a screen reader. Every engagement is tested and signed by a DHS Trusted Tester, Andrew Szigety (certificate TT‑2606‑09221) or an additional tester he selects as needed, and whoever signs is named on the ACR.

The ACR comes in the INT edition, so one document covers WCAG, Section 508 and EN 301 549. Visual fix guides and follow-up reviews are part of every engagement, with the ACR re-issued after each review. Every engagement also includes a ready-to-publish accessibility statement on the W3C WAI model, written from the same findings, so its limitations can shrink with evidence behind each change. Harbor doesn’t publish a fee. It’s set on a free 15-minute call and fixed in writing before you commit. You can read a full sample VPAT/ACR first.

Harbor provides technical audits and conformance documentation, not legal advice. VPAT® is a registered service mark of the Information Technology Industry Council (ITI).

• VPAT vs ACR
• WCAG 2.1 vs 2.2
• EN 301 549 and the EAA
• Read the Sample VPAT/ACR
• Book the 15-Minute Call