Accessibility is not a one-time state. Overlays update, pages get redeployed, and a rule that held up in June can fail in July. Drift Monitor re-runs the witness on a schedule and tells you when something moves.
A witness run is a snapshot of one moment. The web does not hold still. Your team ships a redesign, the overlay vendor pushes a new script version, a marketing page swaps its hero — any of these can flip a rule from held up to did not hold up without anyone touching the accessibility statement.
What "drift" means here
Drift is a change in a finding state between two witness runs on the same page. A rule that passed last cycle and fails this cycle is a regression; the reverse is a recovery. Either way, the public claim on the page may now be out of sync with the live state.
The most dangerous drift is the one nobody notices: a deploy that breaks keyboard focus on checkout while the accessibility statement still promises it. Monitoring exists to catch exactly that window.
How the schedule works
- Drift Monitor re-runs the witness on up to 20 pages on a fixed cadence.
- Each run is diffed against the previous baseline for that page.
- When a finding state changes, you get a notification with the exhibit attached.
The point is not to generate noise. A page where nothing changed produces no alert. You hear from the monitor only when a claim you are publicly making stops matching what the page actually does.
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.