A UserWay accessibility statement can describe process, scope, and review cadence, but it is not the same thing as dated page evidence. Here is how to narrow the claim and test the live page.
A UserWay accessibility statement is a public claim, not just a policy page. It can be useful when it tells visitors what scope was reviewed, how to report barriers, and when the site was last checked. The problem starts when the statement is read as proof that the live page still behaves the way the claim describes. A statement can describe process and intent. It cannot stand in for dated evidence from one named page on one date.
That boundary matters most on sites that rely on a runtime overlay. UserWay can change parts of the live DOM after page load, expose a toolbar, and patch some accessibility attributes in-browser. None of that means a statement generated from vendor language, a template, or a previous review automatically matches what a visitor encounters today on the page that actually matters — homepage, search, signup, checkout, support, or account flows.
What a UserWay accessibility statement can legitimately say
A good UserWay accessibility statement is narrow, dated, and operational. It can tell a reader which pages or sections are covered, which WCAG version the team reviewed against, what testing methods were used, how feedback is collected, and when the language was last updated. Those are process facts. They help a reader understand the scope of the work without turning the statement into a promise that every route still holds up today.
- Scope: which pages, templates, or sections the statement actually covers.
- Testing method: automated checks, manual review, assistive-technology testing, or a combination.
- Known limitations: third-party widgets, PDFs, embeds, or flows that are still under review.
- Support path: a real email address or form where barriers can be reported.
- Review date: when the statement was last checked and when it will be checked again.
The more specific the statement is about scope, method, and review cadence, the less likely it is to drift into a broad claim that the live page can no longer support.
What a UserWay accessibility statement cannot prove
A UserWay accessibility statement cannot prove that the route a visitor opens today still works with keyboard only, still exposes the right names and landmarks, still preserves focus order, or still avoids contrast and form-label failures. It also cannot prove that a vendor-generated template matches the exact claim language your site should publish after recent deploys, CMS edits, app installs, or third-party widget changes. Those are route-level questions, not statement-level questions.
The practical risk is not that a statement exists. The risk is drift: a sentence written at one moment keeps living on the site while the page changes underneath it. A checkout plugin updates. A theme edit changes button names. A support form adds new validation. The statement keeps saying the same thing, but the route no longer behaves the same way. That is exactly where a statement stops being a helpful note and starts becoming an unsupported claim.
How to check a UserWay statement against the live page
The clean way to review a UserWay-backed statement is to pair the statement text with one real route and test that route directly. Start with the page the statement matters for most: homepage, collection page, cart, checkout step, account login, or support form. Quote the relevant sentence from the statement, then run the route under the same conditions a visitor would encounter it. The question is not whether the statement sounds careful. The question is whether the route behavior still supports the sentence.
- Pick one named route that matters to visitors and revenue.
- Quote the statement sentence that appears to cover that route.
- Run automated checks on the route with the overlay active and compare them with the source state where relevant.
- Check the practical user path: headings, landmarks, focus visibility, link/button names, form labels, error recovery, and whether the task can be finished without guesswork.
- If the route changed, narrow the statement before you widen the claim again.
A broad statement can survive internal review and still fail on first contact with a real route. One named-page check usually reveals more than another round of template editing because it ties the claim to observable behavior.
Statement templates and generators vs. dated evidence
UserWay statement generators and vendor templates can still be useful. They help teams remember the ingredients of a complete statement: scope, standard, feedback path, and review cadence. But they solve an authoring problem, not an evidence problem. A generated statement can be structurally complete and still over-claim what the live page currently supports. The safer workflow is to use the template after the route-level review, not instead of it.
If your question is still whether the widget changes the underlying route enough to support stronger language, pair this page with Does the UserWay widget actually make your site WCAG compliant? That post focuses on runtime coverage. This one focuses on what the public statement can honestly say after that review.
How to keep the statement from drifting
A statement usually drifts for mundane reasons: routine content edits, theme releases, third-party app changes, or a team that copied vendor wording and never rechecked it. The fix is operational, not rhetorical. Keep the statement tied to a review date, revisit the highest-risk routes on a schedule, and update the public claim when the route-level evidence changes. The point is not to keep rewriting prose. The point is to keep the claim synchronized with the live page.
Teams that are rewriting broader statement language should also review Writing an accessibility statement when you use an overlay for the generic structure, and How to document website accessibility evidence that holds up for the timestamped exhibit pattern that keeps the route review auditable.
If stakeholders keep pushing for stronger language because a dashboard or score looks reassuring, Website Accessibility Scores: What a 0–100 Number Can Show — and What It Still Can't Prove is the cleanest bridge back to route-level review.
Use a one-page witness to narrow or refresh claim language on the routes your statement appears to cover. The output is evidence about what the page did on one date, not a certification or legal conclusion.
- Free witness: one-page review to narrow a claim against one named route before you refresh public statement language.
- Risk Packet ($49 one-time): a fuller evidence file across 5 to 10 high-risk pages, with claims quoted back, UTC timestamps, and snapshot hashes on each exhibit.
- Drift Monitor ($99/month): scheduled rechecks when the route or overlay behavior changes and the statement may need a refresh.
- Agency Watch ($249/month): the same evidence workflow across multiple client properties and recurring statement-review surfaces.
A UserWay accessibility statement can be useful when it stays scoped to what the team has actually reviewed. It becomes risky when it is treated as proof that the live route still behaves the same way today. Start with the route, keep the claim narrow, and let dated evidence decide what the statement can honestly say next.
Frequently asked questions
- Can a UserWay accessibility statement prove that a page is accessible?
- No. A statement can describe process, scope, and intent, but it does not replace dated evidence from a named live page. You still need route-level testing to know whether the page behavior matches the claim.
- Should a UserWay accessibility statement say the site is WCAG compliant?
- Only if you can support that claim on the exact pages the statement covers. In practice, a narrower statement that names scope, testing method, and known limitations is safer than a broad finished-state claim.
- What is the cleanest way to review a UserWay-backed statement?
- Quote the statement back, test the named routes, and keep the claim language tied to what held up on the live page. If the route-level evidence changes, refresh the statement instead of leaving the old wording in place.