Webscan Documentation

Lesson 18 · Monitoring

Phase 4 · Auditing at scale — Lesson 18 of 21 · All lessons

Objective: understand what monitoring is, schedule automatic repeat scans, and use comparisons and alerts to catch accessibility regressions before your users do.

Before you start: a website you've scanned at least once (Lesson 4).

Accessibility isn't done once

You can scan a site, fix everything, and verify it — and then next week a developer ships a change that quietly reintroduces a barrier. Accessibility is a practice, not a one-time score. Monitoring is how webscan keeps watch for you.

Monitoring — automatically re-scanning a website on a schedule and alerting you when accessibility gets worse, so problems are caught continuously instead of only when someone remembers to look.

Key terms:

• Schedule — the plan for automatic scans: which website, how often.
• Regression — when something that was working breaks again; here, accessibility getting worse than before (new or returned barriers).
• Comparison — webscan's diff between a new scan and an earlier one, showing what changed.
• Alert — a notification webscan raises when a scheduled scan regresses or fails.

Set up a schedule

1. From the website page, open Monitoring and create a schedule with: - a name, - a frequency — Weekly or Monthly, - optionally a scan profile (Lesson 11), so monitoring scans run authenticated and cover pages behind the login, - and an enabled toggle.
2. Webscan then runs that scan automatically at the chosen cadence — you'll see its next run and last run times — with no one having to press Start scan.

You can toggle a schedule off (to pause it) or edit/delete it as needs change.

Comparisons: what changed since last time

Each scheduled scan is automatically compared to the previous one for that website. The comparison classifies the result as an outcome:

To make "what changed" precise, the comparison also counts findings that are new, resolved (gone since last time), and returned (previously fixed, now back). That returned count is especially valuable — it catches fixes that silently came undone.

Alerts: being told when it matters

You don't have to watch the dashboard. Webscan raises an alert when a scheduled scan needs your attention. There are two types:

• Accessibility regression — a scan came back Regressed; new or returned barriers appeared.
• Scheduled scan failed — the automatic scan couldn't run (e.g. the site was unreachable), so you know your monitoring has a gap rather than a false "all clear."

When you've seen and dealt with an alert, acknowledge it — that clears it from the active list and records who handled it, keeping the alert list meaningful.

A healthy monitoring habit

1. Schedule monitoring (weekly is a good default) on the sites that matter, using a scan profile if they're behind a login.
2. Let the baseline establish itself on the first run.
3. When a regression alert arrives, open the comparison, look at the new and returned findings, and turn the real ones into issues (Lesson 7).
4. Acknowledge the alert once it's handled.

That loop turns accessibility from a project you finish into a standard you hold.

Tips & pitfalls

• Use a scan profile for anything behind a login, or monitoring only ever sees your public pages.
• Pay special attention to "returned" findings — they mean a previous fix regressed, which is exactly the kind of silent slip monitoring exists to catch.
• Acknowledge alerts promptly. An unacknowledged pile makes it hard to spot the new, important one.
• A "scan failed" alert is not nothing. It means you have no fresh data — check the site's reachability, as in Lesson 4.

Recap

• Monitoring re-scans on a schedule (Weekly/Monthly) and can run authenticated via a scan profile.
• Each run is compared to the last — Baseline / Improved / Stable / Regressed — with new / resolved / returned counts.
• Alerts fire on regression or scan failure; acknowledge them once handled.
• Together they make accessibility a continuously held standard, not a one-off.

Try it yourself

Create a weekly monitoring schedule for your website (attach a scan profile if it has a login). Note its next-run time, and confirm the first run records as a Baseline. Later, after a change, check the comparison outcome and acknowledge any alert.

Previous: ← Lesson 17 · Prioritisation & the verdict model Next: Lesson 19 · Reports & branding →