OverlayRiskWitness reference
A scannable guide to witness runs, risk packets, finding states, and the engineering surface area behind the product.
Three steps. No code. No setup.
Everything runs in the cloud. You paste a URL, the witness runs, and the result is tied back to the public claim your site is already making.
Point it at a public URL
Enter any public page on your site — your homepage, checkout, or the page named in an accessibility statement. No login, no code change, nothing to install. OverlayRiskWitness only ever tests publicly reachable pages.
Overlay on, then overlay off — in a real browser
A headless browser loads the page twice: once with your accessiBe or UserWay overlay active, and once with it blocked. Both runs execute the same automated accessibility checks (axe-core) so the comparison is apples-to-apples.
Get the per-rule diff
Every WCAG rule is compared across both runs. Rules that changed — better or worse — become findings. Rules that didn't change are noted too. The result is a prioritized list tied to your own public accessibility statement, not the overlay vendor's dashboard.
It does not remediate accessibility issues, does not guarantee legal compliance, and is not affiliated with accessiBe, UserWay, or any regulator. It observes and documents. Evidence, not a compliance ruling.
What's in a Risk Packet
Each packet covers 5-10 high-risk pages on your site. Every exhibit follows the same evidence pattern: claim, observation, timestamp, and page-level context.
Paired overlay-on / overlay-off captures
For each page tested: the axe-core scan results with the overlay running, and the results with it blocked — side by side, same page, same moment.
Timestamp and snapshot hash on every finding
Each capture records the UTC time and a content hash of the DOM snapshot. You can show when the test ran and verify the page state at that moment.
Your own accessibility statement quoted back
Where your site's public accessibility statement makes a specific claim — "meets WCAG 2.1 AA", "keyboard accessible", "compliant" — that claim is pulled in and placed next to the finding it relates to.
A state for each finding
Held up, did not hold up, or not testable. These are observations about one test run, not legal verdicts. Your counsel decides what they mean.
Page URL and rule ID on every exhibit
Each finding names the exact page URL and the WCAG rule (for example: color-contrast, label, aria-hidden-focus). Nothing is anonymized or rolled up.
Sample exhibit
https://example.com/checkout
"This site meets WCAG 2.1 AA and is keyboard accessible."
Checkout button drops out of keyboard focus order. rule: label
- Captured
- Jun 24 2026, 14:02 UTC
- Overlay state
- On
- Rule
- label
- Snapshot
- a3f8d1...c2e9
Every exhibit in the packet follows this format: one claim, one observation, one timestamp.
What each finding state means
Every finding has one of three states. These are observations about one run, not legal conclusions.
- What it means
- The overlay was active and this WCAG rule produced no violations — consistent with the claim on the page. The observation is documented.
- What to do with it
- Your public claim about this rule was consistent with the test result on this page. Keep re-testing as pages and the overlay update — what held up last month may not hold up next month.
- What it means
- With the overlay on, this WCAG rule still showed violations — the overlay did not resolve it. Your public accessibility statement made a claim that this test found inconsistent on this page at this timestamp.
- What to do with it
- This is a documented inconsistency between your public claim and the observed state. It is not a legal verdict. Show it to your counsel — they decide what it means for your situation.
- What it means
- Automated checks couldn't reach or evaluate this rule on this page — because the element wasn't rendered, the overlay blocked the check, or the page requires interaction to load the relevant content.
- What to do with it
- A not-testable finding is a gap in the evidence, not a pass. If this rule matters to a claim you're making, it warrants a manual check.
When a finding is marked did not hold up, all of the following were true at the moment of the test:
- The overlay was active when the page was loaded.
- The same WCAG rule still showed violations with the overlay on.
- Your public accessibility statement made a claim that this test found inconsistent on this page.
- The result is captured with a timestamp and a snapshot hash.
This is not a legal verdict. OverlayRiskWitness documents observations. It does not determine ADA or WCAG compliance, and it does not provide legal advice.
Quick reference
| Observation | What it means | Packet state |
|---|---|---|
| Fixed by overlay | A rule had violations with the overlay off, and zero with it on. The overlay resolved it on this page. | Held up - document it, re-test after overlay updates. |
| Broken by overlay | A rule had no violations with the overlay off, but gained new violations with it on. The overlay introduced the problem. | Did not hold up - relevant to any "we improved accessibility" claim. |
| No effect | The rule's violation count did not change between overlay-on and overlay-off. The overlay neither fixed nor broke it. | Held up if your claim was limited to this rule. Not testable if the rule couldn't be reached. |
| Claim matched | The rule named in your accessibility statement was tested, and the overlay-on result is consistent with the claim. | Held up - timestamped evidence that the claim was accurate at this moment. |
| Claim inconsistent | The rule named in your accessibility statement was tested, and the overlay-on result was inconsistent with the claim. | Did not hold up - the exhibit shows the specific inconsistency. |
REST API and MCP server surface
OverlayRiskWitness is also available as an MCP server and a REST API for teams that want to run witnesses inside CI pipelines, trigger packet generation on deploy, or pull findings into an internal dashboard. Authentication is API-key based; the full endpoint reference covers witness runs, packet retrieval, drift polling, and webhook payloads.
REST witness
Run the public free witness endpoint and inspect the first finding returned to the browser.
curl -sS https://overlayrisk.com/api/witness \
-H 'content-type: application/json' \
-d '{"url":"https://merchant.example/checkout"}'The API sets an HttpOnly witness-session cookie and returns this body on success.
{
"runId": "run_01JYQ6V9D4ZQ4X3H5JY0PQ6S1T",
"siteUrl": "https://merchant.example/checkout",
"overlayVendor": "accessibe",
"pagesTested": 1,
"claimsTested": 1,
"didNotHoldUp": 1,
"freeFinding": {
"claimText": "Merchant says checkout meets WCAG 2.1 AA.",
"pageUrl": "https://merchant.example/checkout",
"ruleId": "image-alt",
"state": "did_not_hold_up",
"exhibit": {
"capturedAt": "2026-06-23T03:00:00.000Z",
"offImagePath": "run-01/finding-01/off.png",
"onImagePath": "run-01/finding-01/on.png",
"snapshotHash": "snapshot-hash-1"
}
},
"lockedFindingCount": 4
}