What Gets Checked

A scan checks pages the way they actually render in a browser, after scripts have run and the page has settled, not the HTML your server sends. That is what assistive technology sees, and it is the only way to judge single-page applications at all.

Which pages

The crawl starts at the start URL and builds its list of pages from, in order:

1. the start URL;
2. the pages you listed under Check these pages first;
3. your sitemap (/sitemap.xml and any sitemap named in robots.txt);
4. links it finds on the pages it checks.

It stays on the start URL's host, honours Skip these paths, ignores downloads (PDFs, images, archives) and treats URLs that differ only by a fragment or a tracking parameter as the same page.

Pages built from one template, such as /products/oak-desk and /products/walnut-shelf, mostly share their problems. So the crawl checks the first few pages of each section, moves on to sections it has not seen yet, and only then comes back for the rest. On a large site the page budget is spread across the whole site instead of being spent on one product listing; on a small site every page is still checked.

The number of pages is set by the scan mode. If the crawl finds more pages than the mode allows, the report says how many were left unchecked.

The checks

Automated rules. Every page is checked against the rules for the WCAG A and AA success criteria that a browser can decide: text alternatives, form labels, accessible names of buttons and links, colour contrast, page language, heading and list structure, ARIA usage, touch target size, links that rely on colour alone, and more. Only rules tied to a WCAG success criterion count; general best-practice advice is left out.

Keyboard walk. The scan presses Tab through the page the way a keyboard user does. For each control that takes focus it compares the screen with and without focus. If nothing on screen changes, the focus is invisible: a failure of 2.4.7 Focus Visible. If focus stays on one control and cannot be moved past it, even with Shift+Tab, that is a keyboard trap: a failure of 2.1.2. Built-in controls with several stops of their own, such as a video player or a date field, are given room before they could ever count as a trap.

Reflow at 320 pixels. The scan lays the page out 320 CSS pixels wide (the width of a desktop browser zoomed to 400%) and measures whether it scrolls sideways, a failure of 1.4.10 Reflow. Content that genuinely needs two dimensions, such as data tables, code, maps and video, is exempt in WCAG, so an overflow caused only by such content is flagged for review, not reported.

Hidden content. Navigation menus, accordions and dropdowns hide content when a page loads. The scan opens each one (only buttons that declare themselves disclosure buttons, never links or form submits), checks what appeared, and closes it again.

What is not reported

A false failure costs your team time and trust, so the scan leaves out anything it cannot be sure of:

• Undecidable results are flagged for review, not reported. Text over an image or a gradient, for example, cannot be measured reliably. Such items are listed separately and never counted.
• Error pages and bot-protection pages are never checked. A page that answers with an HTTP error, or a challenge page from your bot protection, is listed as not checked rather than reported as your site.
• Text inside illustrations. Product screenshots and mock-ups often contain small grey text that is part of a picture. WCAG exempts it, so contrast results inside them are flagged for review, not reported.
• Elements you excluded with Ignore these elements are not checked.

What automated checks cannot see

Many WCAG criteria depend on meaning: whether a text alternative actually describes the image, whether captions match the audio, whether an error message helps. No automated tool can judge these. The report lists every criterion and marks these Needs manual review, so the gap is visible rather than hidden. See Reading the Report.