A witness run produces two axe-core result sets — overlay off and overlay on — and a per-rule diff between them. Here is how to read that diff and what each transition tells you.
axe-core is the open-source accessibility rule engine from Deque. It evaluates a rendered DOM against WCAG success criteria and returns a list of violations, each tied to a rule id and the specific nodes that failed. OverlayRiskWitness runs it twice per page and compares the two result sets rule by rule.
The two passes
The first pass loads the page with the overlay blocked at the network layer, so axe-core sees the site as it ships. The second pass loads the same page with the overlay active and given time to inject its changes. Same URL, same viewport, same rule set — only the overlay differs.
{
"rule": "color-contrast",
"off": { "violations": 4 },
"on": { "violations": 4 },
"transition": "no_effect"
}The four transitions
- Fixed by overlay — violations off, zero on. The overlay genuinely resolved the rule on this page.
- Broken by overlay — zero off, violations on. The overlay introduced the problem.
- No effect — count unchanged. The overlay neither fixed nor broke the rule.
- Not testable — the rule could not be evaluated in one of the passes.
A rule that goes from passing to failing once the overlay loads directly contradicts any "we improved accessibility" claim. It is the strongest single exhibit a witness run can surface.
Mapping the diff to finding states
The packet collapses these transitions into three finding states — held up, did not hold up, not testable — and pins each to the claim it relates to. The raw diff is preserved underneath, so an engineer can always drop back down to the rule ids and node selectors.
The OverlayRiskWitness engineering team builds the two-pass witness runner, the axe-core diff pipeline, and the Risk Packet composer. Every post is grounded in what the engine actually observes on live pages.