WCAG scans that live alongside your change detection
When a client site ships a change, the page you audited last month may no longer conform. Run a full axe-core scan on demand, or flip on Auto-scan and OnChange will re-test every page the moment it changes - diffing violations against an attested baseline and handing you a branded report ready for the client inbox.
Accessibility isn't something you ship once
Every deploy is a chance to break conformance you already paid to achieve. A change-triggered re-test is the shortest path to a credible, billable audit practice.
A11y compliance decays
Every release ships new markup. A marketing tweak strips an aria-label, a rebrand drops contrast below AA, a form refactor loses its input labels. Your last audit was correct on the day you signed it.
Manual re-audits don't scale
You can't retest every page after every deploy. A change-triggered scan tells you exactly which pages regressed so you can focus human review where it matters.
Clients need proof
Legal exposure, VPAT attestations, and procurement reviews all need evidence that the site conforms today, not last quarter. Auto-generated delta reports give you that evidence in one click.
What each scan gives you
Not just a flat list of axe violations. A structured regression snapshot that separates new problems from persistent ones, with the evidence attached.
Real axe-core scans
Every scan loads the page in a headless Chromium browser with the full axe-core rule set injected. That's the same engine used by Deque, Chrome DevTools Lighthouse, and Pa11y — not a cheap HTML parser.
New / persistent / resolved
Each violation is matched by rule + target selector against the previous scan (or the attested baseline if set). You see exactly what regressed since you last signed off, not a flat list of everything.
Attested baselines
Mark any scan as the client's compliance baseline. Subsequent scans diff against that snapshot instead of the most recent, so a VPAT attestation stays meaningful as the site evolves.
Contrast watchdog
Every scan re-computes WCAG contrast ratios. A marketing-team tint that drops below 4.5:1 on body copy gets flagged before your users notice.
Dynamic content probes
Tab order is walked to detect missing visible focus rings. Modal triggers are clicked to verify focus is trapped and Escape closes the dialog. The JS-rendered dynamic stuff your axe check would miss.
Screen reader tree diff
Beyond DOM diffs, we snapshot the accessibility tree Chromium exposes to assistive tech. Landmark changes, missing H1s, and lost accessible names show up even when pixels look identical.
The agency workflow, end to end
Same muscle memory as your existing OnChange workflow. A11y sits next to change detection, not off in another tool.
Add the page to OnChange
Drop in a URL (your client's homepage, a critical flow, a landing page). OnChange starts watching it for text and visual changes immediately.
Scan on demand or on every change
Click Run a11y scan whenever you want a fresh pass, or flip on Auto-scan on change so OnChange re-tests the page automatically the moment it detects a diff.
Attest the baseline
When you're satisfied with the state after remediation, mark the scan as an attested baseline. Future scans diff against it automatically.
Share the delta report
Open the print-ready audit page. It shows new/resolved violations, WCAG levels, impact buckets, and an AI-written summary ready to send to the client.
Why this is different from a standalone a11y tool
Pa11y CI and axe-core are great - but they scan whatever you point them at, on whatever schedule you wire up. OnChange already knows your client sites and already knows when they change. Pairing both removes the busywork: the moment a client deploys, the next scan tells you if your audit is still valid. And the audit report URL is a permalink you can send to the client without screenshotting a CI log.
- Change detection already knows which pages shipped today
- Scans run in the same worker that captures your visual diffs
- Violation history is tied to the monitor, searchable alongside Change rows
- AI summaries written in agency voice, not CI console text
Accessibility audits for agencies
How agencies use OnChange to retain clients through continuous conformance.
OnChange's own accessibility posture
Our current VPAT 2.5 Rev conformance report and remediation roadmap.
Questions you'll get asked
Does this run on every change automatically?
Your choice, per monitor. By default scans are on-demand - you trigger them from a monitor or a detected change. Flip on Auto-scan on change for any monitor and OnChange will enqueue a full axe-core scan every time a text, visual, or API change is detected on that page. The scan runs asynchronously so change detection stays fast, and new violations are diffed against the attested baseline automatically.
How does auto-scan on change work under the hood?
When change detection fires, if the monitor has Auto-scan enabled, we create an AccessibilityScan row and hand it to a separate Celery task. The task spins up Chromium, injects axe-core, captures the accessibility tree, runs the dynamic probes, and compares the result to the previous scan (or the attested baseline if set). The detected Change row gets linked to the scan so both show up side-by-side in the timeline.
Which WCAG version do you cover?
The bundled axe-core 4.10.2 ruleset covers WCAG 2.0, 2.1, and 2.2 at A, AA, and AAA levels. Violations are tagged with their criterion (e.g. 1.4.3, 4.1.2) so you can map directly to a VPAT.
What does the accessibility tree diff catch that axe misses?
Structural regressions. If a page visually looks fine but a landmark was removed, the H1 became an H3, or a button lost its accessible name - axe may not fail on that specific issue, but a screen reader user is affected. The tree diff surfaces those drifts directly.
Can I use this for my existing client audits?
Yes. Attest a scan as a baseline, then share the audit report URL. Your client has proof of the state they approved, and any subsequent regression has a precise diff you can bill for remediation on.
Is this a replacement for a manual audit?
No, and it shouldn't be. Automated tooling catches about a third of WCAG issues. OnChange is a regression guard around your manual audit work, so you know exactly which pages need a human re-audit when the site changes.
Stop re-auditing on every release
Attest a baseline. Watch the site. Re-test only what changed. Bill what you remediate.