No U.S. federal law requires most private businesses to publish a website accessibility statement. But you should have one anyway: it tells visitors with disabilities what standard your site targets and how to reach a human when something is broken — often before that person reaches a lawyer instead. And in some situations, such as selling to EU consumers under the European Accessibility Act or bidding on government contracts, accessibility documentation is effectively mandatory. Here's what belongs in one, what to leave out, and a template you can adapt.
What is a website accessibility statement?
A website accessibility statement is a public page — usually at /accessibility, linked from every footer — that explains, in plain language, your organization's commitment to accessibility. It names the standard you target (for most sites, WCAG 2.2 Level AA), describes your current status honestly, lists known limitations, and gives people a direct way to report barriers.
It is not a legal disclaimer or marketing copy. It's a service page for the more than 1 in 4 U.S. adults living with a disability — telling them what to expect and what to do when something doesn't work.
Is an accessibility statement legally required?
For most U.S. private businesses, no single law says "publish a statement." The ADA itself doesn't even name a technical web standard — courts and settlements simply treat WCAG as the de facto benchmark (more on that in our guide to whether ADA website compliance is required). But there are three situations where accessibility documentation moves from "smart" to "expected":
- You sell to EU consumers. The European Accessibility Act, enforceable since June 28, 2025, explicitly covers e-commerce and requires service providers to publish information about how their services meet accessibility requirements. U.S. companies selling into the EU are in scope — see what the European Accessibility Act means for US companies.
- You sell to government. Section 508 applies to federal agencies and federal procurement, and buyers routinely ask vendors for a completed VPAT (Accessibility Conformance Report); a public statement is the consumer-facing cousin of that document.
- You are a state or local government entity. The DOJ's Title II rule, published April 24, 2024, adopts WCAG 2.1 AA for government web content, with compliance deadlines of April 26, 2027 for entities serving 50,000+ people and April 26, 2028 for smaller ones.
Why publish one if it's not required?
Three practical reasons.
It gives frustrated users an alternative to a demand letter
More than 5,000 digital-accessibility lawsuits were filed in 2025 — up roughly 20% over 2024. A feedback channel won't stop a serial plaintiff, but it gives a genuine customer who hits a barrier a path that isn't "call a law firm." With most cases settling for between $10,000 and $75,000 plus a remediation commitment, a monitored inbox is the cheapest early-warning system you will ever run.
It documents good faith
An honest statement — one that names a standard, describes real testing, and shows a pattern of responding to feedback — is evidence of an ongoing accessibility program rather than indifference. It won't decide a case, but it shapes the conversation.
It keeps your own team honest
Writing "we target WCAG 2.2 AA and here is where we fall short" forces someone to actually know the answer. Many businesses discover their real status for the first time while drafting the statement.
If you don't know your current status, start with a free accessibility audit — you can't honestly describe conformance you've never measured.
What should your statement include?
- The standard you target. Name the version and the level: WCAG 2.2 Level AA (WCAG 2.2 became the W3C Recommendation in October 2023). Vague phrases like "industry standards" help no one.
- Your honest current status. "Fully conformant" is a strong claim — make it only after expert human testing, because automated scanning can detect only roughly a third of WCAG success criteria. "Partially conformant" with a list of known issues is credible and normal.
- Known limitations. Old PDFs, a third-party booking widget, legacy video without captions — name them and say what you're doing about them.
- What you actually do. Expert audits, code-level remediation, screen-reader and keyboard testing, staff training. Specifics, not adjectives.
- A feedback channel and a response commitment. An email address plus a phone number, and a stated response time you can actually meet.
- A "last reviewed" date. A statement dated three years ago says the opposite of what you intended.
The W3C publishes a free accessibility statement generator if you want a second structural reference.
What should you never put in one?
Compliance claims you can't back up. Never state that your site "is ADA compliant" because a tool, scan, or widget said so. Automated tools cover only part of WCAG 2.2; full-conformance language belongs in your statement only after expert human testing verifies it. Overclaiming in a public document hands opposing counsel a quote.
An overlay as your accessibility strategy. The distinction matters: a preference widget — user-facing display settings like contrast and text size, on a site already accessible at the code level, making no compliance claims — is a legitimate convenience; ADA Fail's own site runs one. A "compliance" overlay — a third-party script sold as making a broken site compliant — is a different product entirely, and the FTC fined overlay vendor accessiBe $1 million in 2025 over exactly those claims. UsableNet's reporting repeatedly finds hundreds of companies sued each year already had a widget or overlay installed. If your statement says "we installed an overlay, so we're accessible," you've documented the problem, not solved it. See our guide to accessibility widgets vs. overlays.
Someone else's boilerplate. Copying another company's statement verbatim — sometimes including their contact email — is worse than publishing nothing. Every line should be true of your site.
A website accessibility statement template
Adapt the bracketed parts.
Accessibility statement for [Company Name]
[Company Name] is committed to making [website URL] usable by everyone, including people who rely on assistive technologies such as screen readers. We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA.
Current status. [Website URL] is [fully / partially] conformant with WCAG 2.2 AA. [If partially:] We are aware of the following limitations and are actively working to resolve them: [list them plainly — e.g., "some older PDF documents are not yet tagged for screen readers."]
What we do. Our accessibility work includes [expert audits against WCAG 2.2 AA / code-level remediation / testing with screen readers and keyboard-only navigation / ongoing monitoring between audits]. This statement was last reviewed on [date].
Feedback. If you encounter any barrier on this site, contact us at [monitored email address] or [phone number]. We aim to respond within [X business days] and to fix verified issues promptly. If any content is inaccessible to you, we will provide it in an alternative format on request.
Frequently asked questions
Will an accessibility statement protect me from an ADA lawsuit?
No. Plaintiffs sue over barriers, not missing paperwork, and a statement sitting on top of an inaccessible site changes nothing. What it does is document good faith and create a feedback path that can intercept complaints before they become demand letters. The protection comes from actually fixing the site; the statement is how you communicate that work.
Where should the accessibility statement go on my site?
Put it on a dedicated page (a URL like /accessibility works well) and link it from the footer of every page, next to your privacy policy — that's where screen-reader users go looking for it. The statement page itself must also be accessible — logical heading order, descriptive link text, sufficient color contrast — because an inaccessible accessibility statement helps nobody.
How often should I update my accessibility statement?
Review it whenever the site changes materially — a redesign, a new booking or checkout system, a platform migration — and at least once a year regardless. Update the "last reviewed" date every time, and when audits or monitoring surface new issues, add them to the known-limitations list. An accurate "partially conformant" beats a stale "fully conformant" every day of the week.
Not sure what your statement can honestly say? ADA Fail will run a free WCAG 2.2 audit of your website and tell you, in plain English, what's broken, what it costs to fix, and what you can truthfully publish — code-level findings, no overlays, no vague promises.