How scanning works

Every page is checked twice. The passes look for different things, and the reason for the split is that some accessibility problems are visible in the markup and others only exist once a browser has drawn the page.

The server pass

The server fetches the rendered HTML of the page and runs 36 checks against it. This covers everything that can be settled by reading the document: missing alt attributes, unnamed buttons, skipped heading levels, broken ARIA references, tables without headers, links that do not say where they go.

The page is fetched the way a visitor would receive it, not read out of the database. That matters, because a page builder’s stored content and its rendered output are frequently not the same thing.

When the server cannot reach itself

The server pass needs your site to be able to make an HTTP request to itself, which is called a loopback request. Some hosts block this.

Where loopback fails, the plugin says so rather than reporting a clean page. It can fall back to the stored content in some cases, but it will tell you that is what happened, because a check against stored content is weaker than a check against the real page.

The browser pass

The second pass runs in your own browser, against the page as it was actually painted. It runs 5 checks, and they are the ones no parser can do:

Check	WCAG	Why it needs a browser
Text has too little contrast with its background	1.4.3	The effective background colour depends on everything stacked behind the text
Link inside text is marked only by colour	1.4.1	Requires the computed style of the link and of the text around it
Clickable target is smaller than 24 by 24 pixels	2.5.8	Requires real layout, after CSS
Scrollable area cannot be reached by keyboard	2.1.1	Requires knowing what actually scrolls
Element is hidden from screen readers but still focusable	4.1.2	Requires the computed accessibility tree

Contrast is the clearest example. The arithmetic is trivial; knowing what colour is actually behind the text is not. Where the effective background cannot be determined, because there is an image, a gradient or stacked translucency behind it, the finding is reported as needing a person rather than guessed at.

The browser pass is treated as an untrusted source. A finding naming a check outside the published list of five is discarded rather than stored, so the pass cannot invent checks that were never described in the coverage panel.

Why the two numbers can disagree

If you look at a report mid-scan you may see a score above a list of issues that contradicts it. That happens when the server pass has finished and the browser pass has not. Let both finish before drawing conclusions.

What a scan stores

For each scan the plugin records the findings, the score, and when it ran. Only the most recent scan of each page counts toward site-wide totals, so re-scanning a page does not inflate the numbers.

Scans are a sequence, not a timeline. The plugin never re-scans on its own, so the spacing between points on the trend chart is however often somebody pressed the button.

Where the checks are documented

Every one of the 41 checks, with its WCAG success criterion, severity and whether it can be settled automatically, is listed in Every check. The same information is available inside the plugin, from the coverage panel linked on the dashboard and at the foot of every findings list.