An accessibility statement tells visitors what you are doing to make your website or app usable, where problems remain, and how to get help. The most useful statements are specific enough for a person encountering a barrier to act on immediately.
This guide covers the practical writing process, the difference between ADA obligations and WCAG technical criteria, and a template you can adapt to your own evaluated experience. It complements our guide to transparent website policies.
What an accessibility statement does
A statement is a public service page. It explains your accessibility goal, the current state of the experience, and a reliable route to assistance. It is not a substitute for accessible code, content, customer service, or ongoing testing.
Set expectations
Name the site or app covered and the standard you are working toward.
Describe barriers
Explain affected tasks and alternatives in terms a visitor can understand.
Offer help
Give people a direct way to report problems and request accessible content.
ADA, WCAG, and conformance: what to say accurately
The Americans with Disabilities Act (ADA) is a US civil rights law. The Web Content Accessibility Guidelines (WCAG) are technical recommendations with testable success criteria. A statement can name both, but “ADA compliant” and “WCAG conformant” should not be treated as interchangeable claims.
| Term | What it describes | Safe wording |
|---|---|---|
| ADA | Legal access and effective communication duties in covered settings. | “We work to provide access to our online services.” |
| WCAG target | A technical goal such as WCAG 2.2 Level AA. | “We aim to meet WCAG 2.2 Level AA.” |
| WCAG conformance | An evaluated claim for a defined scope and version. | State only what your assessment supports. |
Legal context
The US Department of Justice explains in its ADA web accessibility guidance that businesses open to the public must make their online offerings accessible, while its guidance does not prescribe one detailed web standard for every Title III business. A separate Title II rule applies to state and local governments; assess that rule independently if it applies to you.
WCAG groups requirements under four principles: perceivable, operable, understandable, and robust. These principles help you organize testing, but a statement should describe the effect on users in plain language. For broader website policy planning, see our website legal requirements checklist.
What to include in an accessibility statement
The W3C’s guidance on developing an accessibility statement recommends a commitment, the standard applied, and contact information as core elements. It also recommends explaining limitations and accessibility measures. Use the six sections below as a drafting checklist.
Scope and commitment
Name the organization, website or app, and the people the statement is intended to support.
Standard and status
State the WCAG version and level you aim for. Claim conformance only when your evaluation supports it.
Measures and evaluation
Describe concrete design, development, content, and testing practices that are actually in place.
Known limitations
Explain affected content or journeys, the user impact, any available alternative, and what you are doing about it.
Feedback and assistance
Give a usable contact method, a way to request an accessible alternative, and a realistic response expectation.
Ownership and review
Identify who maintains the statement and record a real review or publication date when one exists.
Audit before you write
Start with the tasks visitors need to complete: finding information, using navigation, filling forms, checking out, watching media, and opening documents. Combine automated checks with manual keyboard and assistive technology testing. Record each barrier, its impact, owner, alternative, and status. That record gives the statement factual content.
Inventory
List key pages, flows, media, and documents.
Test
Check keyboard use, labels, focus, contrast, and content.
Prioritize
Address blocked tasks and high impact barriers first.
Publish
Describe verified status and usable alternatives.
Example audit snapshot
These two charts show the same fictional 12 issue example. They illustrate how an internal audit can inform a plain language limitations section; the numbers are not research findings or a benchmark for other websites.
| Area | Barriers | Overall status |
|---|---|---|
| Forms | 4 | 5 fixed · 4 in progress · 3 pending |
| Navigation | 3 | |
| Media | 3 | |
| Documents | 2 |
How to write the statement, step by step
- 1
Define the scope
Name the organization and the exact website, app, or service covered. If a third party checkout or embedded tool is excluded, explain the boundary.
- 2
State the goal and evidence
Name the WCAG version and level you target. Describe the evaluation method and avoid a conformance claim you have not verified.
- 3
Describe real measures
Mention practices you can substantiate: content training, keyboard checks, design reviews, captioning, testing, or remediation.
- 4
Explain known barriers
Use a short description of what a person cannot do, which content is affected, and what alternative or support is available.
- 5
Make feedback actionable
Provide a monitored email, form, phone, or other channel. Tell users what information helps your team investigate and when they can expect a response.
- 6
Assign review ownership
Identify who updates the page after fixes, redesigns, and new content. Add a real date when you publish or review it.
Accessibility statement template you can adapt
Replace every bracketed field with verified information. Remove a section if you cannot support its claim, and write limitations in everyday language.
Accessibility Statement for [website or app]
Our commitment. [Organization] is working to make [scope] accessible to people with disabilities. We aim to meet [WCAG version and level, if selected].
What we do. We [list actual accessibility practices, such as testing, training, content checks, and remediation]. We assessed [scope] using [honest evaluation methods].
Known limitations. [Describe each affected feature and what happens.] We are [specific remediation action]. In the meantime, [accessible alternative or support path].
Feedback and assistance. If you have trouble using [scope], contact us at [working email, phone, or accessible form]. Please describe the page and the problem if you can. We aim to reply within [realistic timeframe]. You can also request information in an accessible format.
Maintenance. [Team or role] maintains this statement. [Add an actual publication or review date when the page is published or reviewed.]
Never leave placeholder text, unmonitored contact details, or unsupported “fully compliant” claims on a published page.
Publish, review, and respond
Put the statement on its own accessible page and link it consistently from the footer, help area, or another place visitors can find quickly. Our guide to where to display website policies covers practical placement patterns.
When feedback arrives
- Confirm receipt and offer immediate help with the blocked task.
- Log the barrier with the affected page and assistive technology details where volunteered.
- Assign an owner, test the fix, and update the public limitations section when appropriate.
When to review
- After major redesigns, new features, or platform changes.
- When an important barrier is fixed or a new one is found.
- When contact details, support options, or the accessibility target change.
If you maintain several policy pages, align ownership and review practices with your privacy law overview and the information published through your Privacy Policy Generator.
Common mistakes to avoid
| Weak wording or practice | Better approach |
|---|---|
| “Our site is 100% ADA compliant.” | Describe your actual accessibility goal, evaluation scope, and known issues. |
| Listing WCAG criterion numbers alone. | Explain what the visitor experiences and how to complete the task. |
| A feedback form that cannot be used with a keyboard. | Test the contact route and provide another usable option where possible. |
| A statement with an automatic “updated” year. | Record the date only after a real review or substantive update. |
| Publishing a template without checking it. | Replace placeholders, verify every claim, and assign a responsible owner. |
Frequently asked questions
Does publishing a statement make a website ADA compliant?
No. A statement explains your accessibility work and gives users a way to get help. Accessibility depends on the actual experience, including content, forms, navigation, and support.
Is WCAG 2.2 Level AA required for every US business?
No single WCAG version is prescribed for every business under ADA Title III. WCAG is useful technical guidance; obligations depend on the applicable law and context. The separate ADA Title II web rule for state and local governments uses WCAG 2.1 Level AA, subject to its terms.
Can I say “fully accessible” if an automated scan passes?
An automated scan cannot verify every barrier. Test representative journeys with a keyboard, assistive technology, and people where possible before making broad conformance claims.
Should I disclose unfinished accessibility work?
Yes. Describe known barriers in plain language, provide an alternative where possible, and explain how people can request help. Keep the description current as issues are resolved.
Where should I link the statement?
Place a consistently named link in the footer and consider the help menu, sitemap, and other places where users seek support.
Ready to publish a useful statement?
Check the real experience, describe your goal and limitations clearly, and give visitors a working way to request help. Use the Accessibility Statement Generator to turn those verified details into a draft.