Guide
Accessibility statement examples you can adapt
Three worked patterns, for a small shop, a public sector team and a mobile app. They show the shape of a statement and the level of detail each audience expects. They are patterns to edit, not legal templates, and none of them is a claim about your site.
General information, not legal advice. Replace every bracketed placeholder, and never copy a conformance claim you have not tested.
The structure all three share
The W3C’s minimal example is deliberately short. It contains a commitment, a conformance status that names the guideline and the level, and a feedback section with a phone number, an email address, a postal address and a stated response time. It ends with the date the statement was created.
Everything else is an addition that earns its place: known limitations, the measures you take to keep the site accessible, technical prerequisites such as supported browsers, the laws that apply, and the date of the last review. Public sector statements usually need the enforcement route as well. An app needs the platforms and versions it covers.
One rule sits above all of them: the statement describes evidence. If nobody tested the checkout with a keyboard, do not write that the checkout is accessible.
Example 1: small business
A five-page shop, a booking form and a newsletter. The statement should be one screen long and written by the person who answers the email.
Accessibility statement for [Business name]
[Business name] wants everyone who visits [domain] to be able to browse, book and pay. We are working to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA.
How accessible the site is. We tested [number] page templates on [date] using a keyboard, browser zoom and an automated checker. The site is partially conformant with WCAG 2.2 AA: the main pages and the booking form work with a keyboard and a screen reader, but [known gap, for example the date picker] does not yet.
What we are doing about it. We have booked a fix for [month] and will update this page when it ships. [Optional: a phone line is available on request for anyone who cannot complete a booking online.]
Tell us about a problem. Email [address], call [number] during [hours], or write to [postal address]. We aim to reply within [number] working days and to offer an alternative way to complete the task in the meantime.
This statement was prepared on [date] and last reviewed on [date].
Note the escape hatch. A small business rarely fixes everything at once, and offering a working alternative is more useful to a customer than a promise. It is also the honest thing to publish while a gap is open.
Example 2: public sector body
Public sector statements carry more weight because the duty is statutory in the UK and because the EAA’s information duty applies to covered services. The statement should name the regulations, state the enforcement route, and separate what is fixed now from what is deferred.
Accessibility statement for [Service name]
This service is run by [body]. We want as many people as possible to be able to use it, so we build to WCAG 2.2 Level AA.
Compliance status. This website is [fully / partially / not] compliant with WCAG 2.2 AA. [If partially] The parts that are not compliant are: [content type or component], which [describe the barrier and who it affects].
Preparation of this statement. This statement was prepared on [date]. It was last reviewed on [date]. The service was last tested on [date] by [tester or method], against WCAG 2.2 AA.
What we are doing. [Fix and date], [fix and date]. Where a fix is deferred, the reason is recorded as a disproportionate burden and reviewed on [date].
Feedback and enforcement. Contact [team] at [email] or [phone]. If you are not happy with our response, you can contact [regulator or route named in your jurisdiction].
The UK regulator route and the wording around disproportionate burden come from GOV.UK guidance, not from the W3C example. Use the wording your own jurisdiction publishes. If you operate in several countries, one statement per legal regime is cleaner than a single page hedging across three.
Example 3: mobile app
An app statement lives in two places: a web page at a stable URL, and a short version in the store listing and the in-app settings. The web page can be fuller; the store text has to survive a character limit.
Accessibility statement for [App name]
[App name] is a [purpose] app for [platforms]. Version [x.y] targets WCAG 2.2 Level AA and the platform accessibility APIs on iOS and Android.
How we tested. We tested version [x.y] on [devices] with VoiceOver, TalkBack, large text, bold text and reduced motion enabled. [Number] core journeys were covered: [sign in, search, checkout, support].
Known limitations. [Chart component] is not yet described to screen readers. [Camera upload] has no non-camera alternative. These are scheduled for [release].
Feedback. Email [address] from the app’s Help screen or from this page. We reply within [number] working days. If you cannot complete a task in the app, [phone number] or [web alternative] is available.
Prepared [date]. Reviewed [date]. Applies to version [x.y] and later until replaced.
Two details matter more in apps than on the web. Name the version, because an app statement dates the moment a release ships, and name the assistive technology you tested with, because “accessible” without VoiceOver or TalkBack in the sentence is a guess.
What to change before publishing
- Replace the conformance status with your own result. If you have not tested, write “we are reviewing this site against WCAG 2.2 AA” and give a date. That is weaker but true.
- Name the real contact. A shared inbox nobody reads is a broken feedback mechanism, and the response time you publish becomes the promise you are measured against.
- List gaps by user impact, not by internal ticket. “The date picker cannot be operated by keyboard” helps a visitor. “JIRA-4412” does not.
- Set the review date before you publish. A statement with no review date quietly becomes false.
- Link it everywhere. Footer on the web, settings and store listing for the app. A statement nobody can find helps nobody.
The free statement generator builds the W3C structure with the EAA, BFSG, UK and US references already in place, so you can spend your time on the answers rather than the layout. For the legal background, read theEAA guide.
Six mistakes to avoid
- Claiming full conformance from an automated scan alone.
- Copying another organisation’s statement, including its gaps and its regulator.
- Publishing a contact route that bounces or goes to an unmonitored inbox.
- Listing only successes and no limitations.
- Leaving a preparation date from three redesigns ago.
- Treating the statement as the fix rather than as the description of the fix.
Frequently asked questions
Can I copy another organisation’s accessibility statement?
Copy the structure, never the claims. A statement describes your content, your test results and your contact route. Copying another site’s conformance status makes a false statement about your own product, and it is the sort of error a complaint will expose first.
What is the shortest statement that is still honest?
Three parts: a commitment, a conformance status naming the standard and level, and a feedback route with a response time. The W3C minimal example uses exactly those, plus the date the statement was created.
Should the statement say “fully conformant”?
Only if a full evaluation against every applicable success criterion found no failures. Most sites are partially conformant and should say so, then list the known gaps. An overstated claim is worse than a modest one.
Where should the statement live?
On your own domain, at a stable URL, linked from the footer of every page and from the app’s settings or about screen. A statement nobody can find does not help the visitor who needs it, so treat the link as part of the page template, not as a one-off.
How often should an accessibility statement be reviewed?
At least once a year, and again after a redesign, a platform change or a new feature that affects interaction. The statement carries a preparation or last-reviewed date, so an old date is visible to anyone who checks.
Does a statement make a site legally compliant?
No. A statement is disclosure, not remediation. Under the EAA the underlying service must meet the accessibility requirements, and in the UK public sector the site must meet WCAG 2.2 AA; the statement only explains where you stand.
More wording questions are answered on the AccessProof FAQ.
Sources and last checked
Links opened on 24 October 2026. The examples above are original patterns built from the structure in these sources; they are not reproduced statement text.
- W3C WAI, developing an accessibility statement:w3.org - checked 24 October 2026.
- W3C WAI, minimal accessibility statement example:w3.org - checked 24 October 2026.
- GOV.UK, make your website or app accessible and publish an accessibility statement:gov.uk - checked 24 October 2026.
- GOV.UK, accessibility requirements for public sector websites and apps:gov.uk - checked 24 October 2026.