Webscan Documentation

Lesson 4 · Run your first scan

Phase 1 · Foundations — Lesson 4 of 21 · All lessons

Objective: start an automated scan, watch it run, and confidently read the results page.

Before you start: a website from Lesson 3. (If you used the onboarding fast path, a scan is probably already running — open it from your dashboard's Recent scans and follow along.)

Start the scan

1. Open your website's page and choose Start scan.
2. Webscan queues the scan and takes you to the scan results page.

Behind the scenes, webscan opens each page in a real browser, waits for it to render, and runs the axe-core rule set plus its own checks — up to your page limit.

Watch it run

At the top of the scan page is a status pill that moves through:

• Queued → waiting for a worker,
• Running → actively scanning,
• Completed → done, results are ready,
• Failed → something went wrong (see the troubleshooting note below).

While the scan is queued or running, the page updates itself automatically — you don't need to refresh. When it flips to Completed, the findings appear.

Read the results

Once complete, the scan page has four things worth knowing:

1. The summary

Near the top you'll see how many pages were scanned and a breakdown of findings by severity — Critical, High, Medium, and a Needs review count for items awaiting a human verdict. This is your at-a-glance health check.

Severities mean roughly:

2. The findings list

Below the summary is every finding, each showing its rule, severity, and a priority indicator (webscan's suggested fixing order — you'll learn how that's calculated in Phase 4). Click any finding to open it — that's Lesson 5.

3. Filters

Long lists are easy to tame. Use the filter controls to narrow by:

• search text (rule or description),
• impact (severity),
• WCAG criterion,
• review state (e.g. still needs a verdict).

Choose Apply filters to narrow the list and Clear to reset it. Filtering changes only what you see, never the underlying results.

4. Reports & export

At the top, Export report offers HTML, PDF, and DOCX versions of this single scan — handy for sharing with a stakeholder or client. There are also links to the Prioritisation model and Export verdicts. You don't need these yet; reports get a full lesson in Phase 5.

If the scan fails

A Failed status usually means webscan couldn't reach or render the site. Common causes:

• the base URL is wrong, unreachable, or redirects elsewhere;
• the site is behind a login (that needs authenticated scanning, Phase 3);
• the site blocks automated browsers.

Fix the cause (often the base URL) via Edit on the website page, then start a new scan. A failed scan costs you nothing — just run another.

Tips & pitfalls

• One page only? Your base URL probably redirects to a login or a single-page entry point. Note it for the authenticated-scanning lesson; don't force it here.
• The numbers aren't the verdict yet. A scan reports candidates. Some are false positives. The next lessons turn raw findings into confirmed, trackable work — resist the urge to treat the raw count as your to-do list.
• Rescan freely. Scans are cheap and repeatable. Change the page limit or fix the URL and run again whenever you like; each run is kept in Scan history.

Recap

• Start scan from the website page; watch the status pill move Queued → Running → Completed (the page auto-updates).
• The results page shows a severity summary, the findings list with priority, filters, and report exports.
• A Failed scan is almost always a URL/reachability problem — fix and rerun.

Try it yourself

Run a scan to completion. Read the severity summary out loud, then use the filters to show only Critical and High findings. Pick the top one — you'll dissect it in the next lesson.

Previous: ← Lesson 3 · Add your first website Next: Lesson 5 · Anatomy of a finding →