Accessibility guarantee vs independent evidence: what site owners should keep

A guarantee sounds clean. A badge sounds final. An accessibility statement sounds like the work is closed. The problem is that none of those artifacts show what actually happened on the page a visitor loaded today.

If your site runs an accessibility overlay, the useful question is narrower: when the page was loaded in a real browser, what changed with the overlay on, what stayed broken, and which public claims did that evidence touch?

What a guarantee does not show#

A guarantee is usually a vendor promise about process, coverage, support, or risk sharing. It may matter commercially. It may help explain why a team bought a tool. It still does not answer the operational question a site owner needs to answer after each deploy.

• It does not show whether the overlay script loaded on a specific page.
• It does not show whether axe-core observed fewer violations after the overlay injected.
• It does not show whether the page had source-level issues the overlay could not reach.
• It does not show whether an accessibility statement still matches the current page.
• It does not show whether a redesign, app release, or vendor update changed the result later.

What independent evidence should contain#

A useful evidence record is boring in the right way. It should be specific enough that another reviewer can understand the input, the test condition, and the observed result without relying on a marketing claim.

• The tested URL, including the exact page path.
• The overlay vendor observed on the page, such as accessiBe or UserWay.
• The browser condition: overlay blocked versus overlay active.
• The automated rule engine used, including the rule ids that changed or did not change.
• The public claim being checked, quoted back when the site publishes one.
• A UTC timestamp and snapshot reference so the evidence is tied to a moment.

For teams turning that checklist into an actual packet, use How to document website accessibility evidence that holds up for the exact URL, timestamp, snapshot-hash, claim quote, and first-broken-step structure that keeps the record tied to one page instead of one broad guarantee.

Where overlays can help#

This is not an argument that overlays never do anything. A runtime script can patch parts of the live DOM, add labels, inject ARIA attributes, or provide user controls. On some pages, those changes can reduce automated findings. That result is worth recording.

The evidence problem starts when a partial runtime change is treated as a permanent site-wide guarantee. The page may still contain issues outside the overlay path: document links, media captions, source order, custom controls, contrast inside images, or checkout flows that change after release.

What to keep after each release#

For site owners, agencies, and ecommerce teams, the practical record should be tied to the moments when risk changes: launch, redesign, checkout update, theme change, plugin update, or accessibility statement refresh.

• Run a witness on the pages named or implied by the accessibility statement.
• Keep the before/after rule diff, not only a pass/fail badge.
• Flag rules that did not hold up with the overlay active.
• Refresh the evidence after meaningful page or vendor-script changes.
• Use the evidence to decide whether to fix source markup, revise a claim, or monitor drift.

How OverlayRiskWitness fits#

OverlayRiskWitness loads a public URL twice in a hosted browser: once with the overlay blocked and once with the overlay active. It runs the same automated checks in both passes, compares the results, and records the finding as held up, did not hold up, or not testable.

The output is not legal advice and not a compliance certificate. It is a timestamped evidence record that helps a site owner see whether an overlay-backed claim has page-level support.

Start with the free one-page witness. If the first finding matters, use a Risk Packet for the pages your statement, checkout, or client agreement actually depends on.