Most accessibility statements on small business sites were pasted in from somewhere else. You can usually tell: “We are committed to ensuring our website is fully accessible to all users,” a reference to a standard nobody tested against, and an email address that bounces. Then a visitor who uses a screen reader hits a checkout button with no name, goes looking for help, and finds a page that promises something the site plainly does not do. A good accessibility statement for website visitors does the opposite. It says what you aimed for, what you checked, where the site still falls short, and how someone can reach a human who will help. We draft that page from real audit results and keep it current as the site changes.
What an accessibility statement is actually for
Think of the statement as a help page for a specific group of visitors, not as a legal shield. Someone who is blind, has low vision, uses a switch device, is deaf or hard of hearing, or has a cognitive disability arrives at your site and runs into something that does not work for them. The statement tells them three things quickly: you know accessibility matters, here is what you already know is broken, and here is how to get what they came for another way.
It also does quieter work. Writing one forces an organization to decide who owns accessibility, which standard it is working toward and how complaints get answered. A statement nobody inside the business has read is a warning sign. One that names a team and a review date shows the work is being looked after.
What it cannot do is make a site accessible, or protect anyone from a complaint. We are not attorneys, and this page offers no legal advice. Anyone holding a demand letter should talk to their lawyer first and see our page on the technical side of a demand letter response; the statement can wait until the facts are clear.
What goes into an accessibility statement for website readers
There is no single required format for private US businesses, but most useful statements cover the same ground. The W3C’s Web Accessibility Initiative publishes guidance on statements, and its outline is close to what we use.
- Your commitment, in one or two sentences. Plain words, no superlatives.
- The standard you are working toward. Usually WCAG 2.2 Level AA, named exactly, with the level.
- Current status. Whether the site partially conforms, and what that means in practice.
- How you checked. Automated tools, keyboard testing, screen reader testing, who did it and when.
- Known limitations. Specific areas that still have barriers, with a workaround for each.
- Third-party content. Embeds, payment pages or booking tools you do not control.
- Feedback and contact. At least two ways to reach a person, and what happens after someone writes.
- Dates. When the statement was written, when the site was last tested, when it will be reviewed next.
Some organizations add a short list of accessibility features, such as a skip link or captions on every video. That can help, but keep it to things a visitor can actually use, not a list of technical achievements.
Where to put it
An accessibility statement for website visitors only helps if they can find it. Link it from the footer on every page, using a plain label such as “Accessibility.” Visitors look for it there. Hiding it inside a legal or privacy page makes it much harder to find for the very people it is written for.
Wording that does not overclaim
This is where most statements go wrong. A sentence like “this website is ADA compliant” claims a legal status no web page can grant itself. “Fully accessible to everyone” is a promise no site can keep, because needs vary and pages change weekly. These phrases do not reassure the visitors who need help; they only make the gap more obvious when something fails.
Here are the kinds of rewrites we make:
| Common wording | Problem | Honest alternative |
|---|---|---|
| “Our website is fully ADA compliant.” | Claims a legal result; ADA has no website certification | “We are working toward WCAG 2.2 Level AA across this site.” |
| “Accessible to all users.” | Cannot be true for every person and every page | “Most pages partially conform to WCAG 2.2 AA. Known gaps are listed below.” |
| “We use an AI tool that makes the site accessible.” | Credits a widget for work it does not do | “We test with a keyboard and screen readers and fix issues in the site’s code and content.” |
| “Certified accessible.” | No such certification exists for a website | “Last tested in [month and year] by an outside reviewer; next review planned for [month].” |
| “Contact us with any issues.” | No channel, no owner, no follow-up | “Email or call our accessibility contact, named below. We reply to every message.” |
“Partially conforms” can feel like an admission. It is just accurate. The W3C’s own statement guidance uses the term for content where some parts do not yet meet the standard, and it is the right description for most real sites at most moments.
If an overlay is installed
Many statements we are asked to revise were written by an overlay vendor and describe the toolbar as the accessibility solution. If that widget is still on your site, the statement should not lean on it. Better still, remove it and fix the underlying issues; the overlay removal and replacement service handles that, and the post explaining how overlay toolbars work under the hood fills in the background.
A feedback channel someone actually answers
The contact section is the part visitors use. Make it work for people with different disabilities, which means offering more than one route.
- An email address that goes to a monitored inbox, not a no-reply address and not a general sales queue that gets triaged by a bot.
- A phone number, with the hours someone answers it.
- A simple form, if you want one, that itself passes a keyboard and screen reader check. An inaccessible feedback form is an all too common irony.
- A named role, such as “office manager” or “web team lead,” so messages have an owner.
Then decide internally what happens to a message. Who reads it? How does the person get what they were trying to do, today, while the fix waits? Where does the issue get logged so it reaches whoever maintains the site? We write those steps into a short internal note that sits beside the public statement.
Do not promise a reply within a set number of hours unless you are sure you can keep it every time. “We aim to reply promptly and will offer another way to complete your task” is better than a deadline you miss once.
Writing the known limitations section
This section is where an honest statement earns trust. Each limitation should name a place, say what does not work and offer an alternative. Vague lines such as “some older content may not be accessible” tell the visitor nothing.
Better examples look like this:
- “Our 2019 to 2022 newsletters are scanned PDFs without readable text. Email us and we will send the text of any issue.”
- “The appointment booking calendar is supplied by a third party and cannot be used fully with a keyboard. Call the front desk to book.”
- “Product videos added before last spring have automatic captions that have not yet been corrected. We are reviewing them in order of views.”
- “The store locator map is hard to use with a screen reader. Every location is also listed as text on the Locations page.”
Notice that none of these hide the problem, and each one gives the visitor a way forward. That is the standard we hold the section to. When an issue is fixed, it comes off the list and the date changes.
How we draft the statement from audit results
We do not write a statement from a template and a guess. It comes from evidence. If we have audited the site already, we work from that report. If not, we start with an audit, because there is no honest way to describe the site’s status without one; the WCAG audit service page explains what the testing covers.
- We read the audit findings and group open issues by where a visitor would meet them.
- We check with you which third-party tools are embedded and who controls each one.
- We draft each section in plain English, including the limitations and their workarounds.
- We agree the contact routes with you and write the internal handling note.
- You review the draft. Someone at your organization approves it, because it is your statement.
- We add the page in WordPress, link it from the footer and test the page itself with a keyboard and screen reader.
If your organization works with federal buyers, the same findings can support an Accessibility Conformance Report; see our Section 508 review and ACR support page for how the two documents differ.
What you get, and what we need from you
You receive:
- The finished statement, published as a WordPress page or handed over as text if your team prefers to post it.
- A footer link labeled plainly on every page.
- A known limitations list tied to specific audit findings.
- An internal note describing who handles feedback and how.
- A short review calendar showing when the statement should be checked again.
We need from you:
- A recent audit, or agreement to run one first.
- The name or role of the person who will own accessibility feedback.
- Working contact details for that person or team.
- A list of embedded services, such as booking, chat, payments, maps or video hosts.
- Edit rights to add a page and change the footer menu, or someone on your side who can.
Keeping the statement current
A statement dated three years ago with a list of issues that were fixed long ago is almost as unhelpful as one that lists nothing. It suggests nobody is watching. Set a review date when you publish, and keep it.
We suggest reviewing it at least once a year, and also after any of these: a redesign or new theme, a new checkout or booking tool, a large batch of new documents or videos, an audit or retest, or a pattern of feedback pointing at the same problem. Each review updates the “last tested” date, removes fixed issues and adds new ones honestly.
Our month-to-month accessibility monitoring keeps a running log of issues, which makes these reviews quick: the statement is just a public summary of what the log already says. Our article about how routine updates undo accessibility fixes explains why that log changes more often than people expect.
How to judge whether your statement is honest
Read your current statement with these questions in mind:
- Does every claim match something a tester could confirm on the site today?
- Is the standard named exactly, with version and level?
- Are there specific known limitations, or none at all? A list of zero on a real site is rarely true.
- Can you send an email to the address listed and get a reply from a person?
- Is the statement page itself usable from a keyboard, with proper headings?
- Are the dates within the last year?
If you answer no to any of these, the statement needs work. If the answer to the email question is no, fix that first; it matters more than any wording.
Mistakes that make a statement backfire
- Copying another company’s statement. It describes their site, their testing and their contact routes, none of which are yours.
- Generating it with a tool and never editing it. Generators help with structure, but the facts have to come from your site.
- Naming a standard you never tested against. If no one has checked the site, say that work is starting, not that it conforms.
- Listing no limitations. It reads as either untested or unwilling to say.
- Hiding the page. If it is not in the footer, the people it serves may never find it.
- Letting the contact address die. Staff leave, inboxes get closed, and the one route a visitor had goes silent.
Writing it yourself or getting help
You can write an accessibility statement yourself if you already have recent test results and a clear owner for feedback. Start from the WAI guidance, describe your own site, and resist the urge to make it sound better than it is. Our small business accessibility checklist is a reasonable way to gather rough facts if you have nothing else, though it does not replace a proper audit.
Help makes sense when you do not have test results, when the site has many third-party tools whose status you cannot judge, or when an old vendor-written statement needs to be unpicked carefully. When you talk to anyone offering to write one, ask: what testing will the statement be based on? Will it list known limitations? Who approves the final wording? Will you update it after fixes? If they offer a statement without testing, or promise it will keep you out of trouble, look elsewhere.
Where the statement fits in looking after a WordPress site
The statement is the public face of ongoing work. Behind it sit the audit, the fixes, the retests and the routine checks that catch regressions after plugin and theme updates. On a site we already look after through monthly WordPress care, updating the statement becomes one more line in the routine rather than a separate project. You can see how the statement connects to the rest of our audit, fixing and monitoring work on the website accessibility hub.