By Mehdi HassanWhat should a website accessibility statement include?
A website accessibility statement should include your commitment, the standard you target, your current conformance status, known issues and workarounds, how you tested, how to contact you about barriers, and the date it was last reviewed. Those seven parts answer what users, buyers and regulators want to know: how accessible is this, what's broken, and who do I tell.
- Commitment. One or two plain sentences on why accessibility matters to you.
- Standard. The guideline and level you aim for, normally WCAG 2.2 Level AA.
- Conformance status. Fully, partially or not conformant, stated honestly.
- Known issues. What doesn't work yet, who it affects, the workaround and the planned fix date.
- How you tested. Self-assessment, external audit or both, and when.
- Feedback and contact. An email, phone number or form, and how fast you respond.
- Review date. When the statement was written and last checked.
The statement sits on top of the real work, not in place of it. If you haven't tested the site yet, start with our guide on how to test website accessibility, and read the website accessibility compliance hub for the legal background.
Do you legally need an accessibility statement?
Whether you legally need an accessibility statement depends on where you operate. Under the European Accessibility Act, providers of covered services, such as e-commerce services sold to EU consumers, must give information on how the service meets the accessibility requirements, and a public statement is the usual way. Public-sector bodies in the EU have had a separate statement duty for years.
In the US, the ADA doesn't require a statement for private businesses. It's still worth publishing one. It gives users a route to report barriers before they turn into complaints, it shows good faith, and enterprise and public-sector buyers often ask for it during procurement. Our guide to ADA website compliance covers the wider US picture.
Situation | Is a statement expected? | Notes |
|---|---|---|
Covered service sold to EU consumers | Yes, under the EAA's information duty | Put it in terms or a linked public statement |
EU public-sector website | Yes, under the EU web accessibility rules for public bodies | Usually follows a set model |
US business website | Not required, recommended | Good-faith evidence and a feedback route |
B2B SaaS selling to enterprise | Commonly requested | Often alongside a conformance report |
Microenterprise exempt from the EAA | Not required | Still useful for users and buyers |
What does the accessibility statement template look like?
Here's an accessibility statement template you can adapt. Replace the text in curly braces, delete anything that doesn't apply, and keep the language plain: the statement itself must be accessible and easy to read.
Accessibility statement for {Company name}
{Company name} wants everyone to be able to use {website or product name}, including people who use screen readers, keyboard navigation, magnification, voice control or other assistive technology. This statement applies to {domain, and app names if included}.
Our standard
We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. {If you serve EU consumers: We also follow the European standard EN 301 549 for the parts of our service it covers.}
Conformance status
{Website name} is {fully / partially / not} conformant with WCAG 2.2 Level AA. Partially conformant means some parts of the content don't yet fully meet the standard. The known issues are listed below.
Known issues and workarounds
{For each issue: what it is, which pages or features it affects, who it affects, how to get the same result another way, and when you plan to fix it. See the example table below.}
How we tested
We last assessed this site on {date} using {self-assessment with automated tools and manual keyboard and screen-reader testing / an external audit by an independent reviewer}. We retest after major changes.
Feedback and help
If you run into a barrier, tell us at {email} or {phone}, or use {form link}. Tell us the page and what you were trying to do. We aim to reply within {number} business days and can provide information in another format on request. {If in the EU: You can also contact {national enforcement body} if you're not satisfied with our response.}
Review date
This statement was prepared on {date} and last reviewed on {date}.
How do you write the known issues section honestly?
Write the known issues section as a short, specific list in plain language: what doesn't work, who it affects, how to get around it, and when it'll be fixed. Vague lines like 'some content may not be fully accessible' tell users nothing and suggest you haven't looked. Specific issues with dates show you have.
Issue | Who it affects | Workaround | Planned fix |
|---|---|---|---|
Embedded scheduling widget can't be used with a keyboard | Keyboard and screen-reader users | Email us to book and we'll schedule it for you | Replacing the widget by {date} |
Older blog posts have charts without text descriptions | Screen-reader users | Contact us for a text summary | Adding descriptions by {date} |
Product demo video has no audio description | Blind and low-vision users | A written walkthrough is linked under the video | Adding description by {date} |
PDF price sheet isn't tagged | Screen-reader users | The pricing page has the same information | Retiring the PDF by {date} |
Every known issue should have a real workaround. If the workaround is 'contact us', make sure someone actually monitors that inbox and knows what to do. And don't list issues you could fix in an hour; fix them instead.
What does a filled-in accessibility statement example look like?
A filled-in accessibility statement for a small SaaS company usually fits on one screen. Below is a hypothetical example, written for an imaginary company, to show tone and length. It isn't a real client and the details are illustrative.
Hypothetical accessibility statement example: an imaginary SaaS company
Accessibility statement for Northwind Analytics (a fictional company). We want everyone to be able to use northwind.example and the Northwind app, including people who use screen readers, keyboards, magnification or voice control.
Our standard: we aim to meet WCAG 2.2 Level AA and, for EU customers, EN 301 549.
Conformance status: our marketing site and signup flow are partially conformant with WCAG 2.2 AA.
Known issues: the interactive pricing calculator can't be operated by keyboard; the same prices are listed in a table below it, and we're rebuilding the calculator this quarter. Two older webinar recordings lack captions; transcripts are available on request.
How we tested: self-assessment with automated tools plus keyboard and VoiceOver testing on our main pages and signup flow, most recently this spring.
Feedback: email accessibility at our domain. We reply within two business days and can send any content in another format.
Prepared and last reviewed: dates listed here.
Where should you publish an accessibility statement?
Publish your accessibility statement on its own page, linked from the footer of every page, and reference it in your terms if you provide covered services in the EU. Users expect to find it in the footer next to privacy and terms. Add it to the legal or company group in your SaaS website sitemap so it's planned from the start, not bolted on after launch.
If you sell to enterprise, link it from your trust or security page too, and keep a PDF-free version: the statement itself must be accessible. When you brief an agency for a new site, list the statement page in your website design brief and the statement of work, so writing and testing it is part of the scope.
How do you keep an accessibility statement up to date?
Keep an accessibility statement up to date by tying it to your release process. A statement that lists issues fixed a year ago, or misses new ones, is worse than none. Use this routine.
Retest after big changes
Rerun scans and a keyboard and screen-reader pass after any redesign, new template, new flow or new third-party embed.
Update the known-issues table
Remove fixed issues, add new ones with workarounds and dates.
Log feedback
Record each user report, the response and the fix. Patterns tell you what to prioritize.
Review yearly at minimum
Change the review date only when you've actually checked the content again.
Get an external check when stakes rise
Before a major enterprise deal or EU launch, consider a manual audit. Our accessibility audit cost guide explains scoping.
If you're working through the technical fixes yourself, the WCAG 2.2 checklist splits them by copy, design and development.
