Accessibility statement best practices change when a third-party overlay is in the picture. An overly broad claim can create more legal exposure than no statement at all — here is how to write one that holds up.
An accessibility statement is not a badge or a formality. It is a public claim. When you publish language like "this site meets WCAG 2.1 Level AA," you are making a representation that can be read by a plaintiff, reviewed by an expert, and tested against the live page in a real browser. If the page contradicts the statement, that gap is the case. The statement did not protect you — it gave someone a target.
That dynamic becomes sharper when you use an accessibility overlay. Overlays — accessiBe, UserWay, and similar tools — promise to close the gap between a site and its compliance claims. Whether they do depends on the specific page, the specific rules, and the specific overlay version that is running on the day someone checks. A statement written before you had that evidence is a statement written blind.
What a public accessibility statement actually is
Under Section 508, the European Accessibility Act, and increasingly under ADA enforcement theory, an accessibility statement is a formal record of a site's conformance status. In practice most statements on smaller commercial sites are borrowed from templates or generated by overlay vendors and published without verification.
That matters because the statement is public-facing and durable. It persists after the overlay vendor updates their script, after your team ships a redesign, after the page you tested against changes. The claim outlives the moment you made it. A lawyer testing your site in nine months will read the statement first, then open your page.
The over-claim problem — and why it creates exposure
The single most common accessibility statement best practice violation is the all-or-nothing claim: "this website is fully compliant with WCAG 2.1 Level AA." That sentence is almost never true for a site of any meaningful complexity, and it is especially risky when an overlay is your primary compliance mechanism. Overlays operate at the DOM surface. They can relabel some elements, add ARIA attributes, adjust inline styles. They cannot rewrite the underlying DOM structure of third-party embeds, dynamically injected content, or PDFs linked from the page.
OverlayRiskWitness loads a page twice in a real browser — overlay off, then overlay on — and runs axe-core (Deque's WCAG engine) on both. Rules that still fail with the overlay running are ones the overlay did not fix, regardless of what the accessibility statement says about them. That gap between statement and observation is exactly what surfaces in a demand letter.
What a good accessibility statement includes
The goal is a statement that accurately describes what you have actually verified, names what you have not, and gives users a clear path to report problems. Specificity is protection. Vagueness is not.
- Scope — which pages or sections the statement covers. "This site" is too broad if you have third-party booking widgets, embedded maps, or legacy PDFs you have not tested.
- Standard and level — name the version you tested against (WCAG 2.1 AA, not just "WCAG"). Referencing a standard that has been superseded or citing a level you cannot demonstrate is a red flag in any review.
- Testing method — state how you assessed conformance. Automated tool only, manual review, assistive-technology user testing, or a combination. Each has different weight.
- Known limitations — list specific pages or features that are not fully conformant and what you are doing about them. Naming a known gap honestly is far better than making a blanket claim that does not survive a single scan.
- Date — when the statement was last reviewed. A statement with no date is a statement with no accountability.
- Contact path — a real email or form where users can report barriers. Under WCAG 2.5.3 and basic fairness, someone who cannot use your site needs a way to ask for help.
Writing the statement when an overlay is in the picture
If you use an overlay, the statement should say so. Describe what the overlay is intended to do, acknowledge that automated fixes address a subset of WCAG success criteria, and avoid implying the overlay closes the conformance gap entirely. The following template is a starting point — it is deliberately conservative. Fill in the brackets with verified, specific information before publishing.
Accessibility statement for [Site Name]
Last reviewed: [YYYY-MM-DD]
[Site Name] aims to meet WCAG 2.1 Level AA where technically feasible.
Scope
This statement covers pages under [domain]. It does not cover
[third-party embeds / linked PDFs / subdomains] — see notes below.
Current status
We use [overlay name] to assist with some WCAG success criteria.
We have independently verified the following pages using automated
testing (axe-core): [list pages].
Known limitations
- [Feature or page] does not currently meet [SC number].
We are [action and timeline, or "aware and investigating"].
Assistive technologies tested
[Screen reader + browser pairs you actually tested, or "not yet tested."]
Feedback and contact
If you experience a barrier, email [address] or use [form link].
We aim to respond within [N] business days.
This statement was prepared on [YYYY-MM-DD] and is reviewed
on a [quarterly / monthly] schedule.Notice what the template does not include: a claim of full conformance. It names what was tested, by what method, and on which pages. It links the overlay to a specific role rather than treating it as a blanket solution. And it builds in a review schedule, because a statement without one is already drifting the moment you publish it.
Statements drift — and so does your exposure over time
The biggest hidden risk of any accessibility statement is not what it says on the day you write it. It is the gap that opens between the statement and the live page in the weeks and months that follow. Your team ships a new feature. The overlay vendor pushes a script update. A third-party widget changes its DOM structure. Any of these can take a rule that the overlay was handling and leave it unresolved, while your public statement still names it as conformant.
This is not a hypothetical. Overlay vendors release new script versions without announcing them to site owners. The version that was active when you wrote the statement may not be the version running when someone checks. A Drift Monitor that re-runs the before/after witness on a regular schedule does not close that gap automatically, but it tells you the gap exists before someone else discovers it.
Start with the evidence, then write the statement
The practical sequence matters. Most sites write the accessibility statement first — often by accepting an overlay vendor's default template — and never verify whether the page matches it. The better order is the reverse: run an independent check of your pages with the overlay active, see which rules hold up and which do not, and write the statement to describe that observed reality.
If the internal conversation is still anchored to a vendor dashboard or Lighthouse number, Website Accessibility Scores: What a 0–100 Number Can Show — and What It Still Can't Prove is the clearest bridge between a reassuring score and the narrower question your statement still has to survive on one named page.
Teams that inherited a vendor badge, certificate, or guarantee can also use Accessibility guarantee vs. independent evidence to separate statement language from the release-by-release record they actually need to keep.
A free witness run on one page shows which rules held up and which did not hold up under your overlay, quoted next to any claims your existing accessibility statement makes about those rules. A $49 Risk Packet extends that to 5-10 high-risk pages with timestamped exhibits. Drift Monitor ($99/mo, up to 20 pages) re-runs the witness on a schedule and alerts you when a finding state changes. None of this is legal advice — it is the evidence you need before writing or updating a statement that you intend to stand behind.
A statement that reflects your actual tested state — including known gaps — is more defensible than a broad claim you cannot substantiate. It shows you took the question seriously, investigated it, and were honest about what you found. That is the core of accessibility statement best practices: not perfection, but accuracy.
Frequently asked questions
- Can an accessibility statement increase my legal exposure?
- Yes. A statement that claims full WCAG conformance while the live page fails the rules it names creates a documented gap between your public claim and observable behavior — which is precisely what a demand letter is built around. A narrow, accurate statement is safer than a broad one.
- Should my accessibility statement mention the overlay vendor?
- Be accurate about what is actually true on the page rather than repeating a vendor compliance promise. Claim only what you can show holds up under testing, and describe your remediation process instead of asserting a finished state.
- How do I know which claims are safe to make?
- Run a witness on the pages your statement covers. It shows which rules held up and which did not under your overlay, quoted next to the claims you intend to publish — so the statement reflects evidence, not assumption.