TestKase
TestKase
|Docs
Accessibility TestingScans

Website Scanner

Scan up to 10 URLs per run with a chosen WCAG version and rule pack.

The Website Scanner runs axe-core against each URL in a real desktop browser from the TestKase Device Farm — the same fleet that powers Live and Automate — and produces a unified report for all URLs in the scan. You pick the browser, operating system, and version; the report records exactly what it ran on.

Accessibility testing is free. Because scans use real farm browsers, they draw on your DeviceFarm plans: manual scans use your Live Browser plan (or its 15 free lifetime minutes) and scheduled scans use your Automate plan (or its free minutes). See Scan limits.

When to use it

  • Target pages are reachable on a direct URL (public or single-sign-on that carries auth via cookies).
  • You want per-URL and roll-up severity counts in one report.
  • You need formal WCAG conformance output (the Website Scanner drives the conformance matrix).

For pages behind a login form, use Authenticated Scanning. For bugs that appear only after a user action, record the flow with the Chrome Toolkit and read it in the Workflow Analyzer.

Create a scan

  1. Sidebar → Website Scanner → New website scan. (The form it opens is headed New Scan.)

  2. Enter a scan name (auto-suggested from the first URL's domain; edit any time).

  3. Add URLs, one of three ways:

    • Type a URL and press Enter or click Add page. https:// is auto-prepended if you don't type a protocol.
    • Upload CSV — a plain list of URLs, one per line.
    • Add sitemap — paste a domain or a direct sitemap.xml URL and pick which of the URLs it finds to add.

    Up to 10 URLs per scan; duplicates are rejected. See Adding URLs in bulk.

  4. Pick where the scan runs with the Run on picker — browser (Chrome, Firefox, or Safari engine), operating system, and version. The default is Chrome on Windows, latest version. See Browser & OS picker below.

  5. (Optional) Click Scan Settings — the labelled button above the URL input — and adjust WCAG version, rule toggles, or authentication.

  6. Click Create Scan.

Adding URLs in bulk

Both bulk paths add every URL they produce to the list. Neither of them stops at 10, and the form does not warn you — the scan is only refused when you click Create Scan, with "A scan can include at most 10 URLs". Trim the list before you submit.

Upload CSV

Upload CSV, next to Add page, takes a plain text file with one URL per line:

url
https://example.com/
https://example.com/about
https://example.com/contact
  • The file must end in .csv — anything else is rejected with "Please upload a .csv file", and a binary file with "Invalid file format. Please upload a valid CSV text file."
  • A first line of url (in any case) is treated as a header and skipped. Any other first line is treated as a URL.
  • It is a one-column file, not a spreadsheet — the whole line is read as the URL, commas included. Don't add extra columns.
  • Lines that aren't valid URLs are dropped silently. Nothing tells you which, or how many. If nothing at all parses you get "No valid URLs found in the CSV file."
  • Duplicates — inside the file and against URLs already on the form — are removed. A toast reports how many were actually added, so compare that number with your file's line count.

Add sitemap

Paste a domain (TestKase looks for /sitemap.xml, /sitemap_index.xml, then robots.txt) or a direct sitemap URL, or use Upload XML to supply a sitemap.xml file you already have. The URLs come back as a folder tree you can tick through, then Add N selected URLs puts them on the form.

Limits on a fetched sitemap:

LimitValueWhat you see
URLs returned500The picker says "showing 500 of N". The rest are dropped, not paged — there is no way to reach them from here
Child sitemaps read from one sitemap index10The 11th onwards are ignored, with no message
Levels of sitemap index followed2A third level of index is not expanded and contributes nothing
Response size10 MB"Unable to fetch sitemap from … Please verify the URL is correct."
Fetch timeout15 secondsThe same message — retry, or upload the XML instead

A child sitemap that fails to fetch is skipped quietly; the rest of the index still loads, so a short result can mean a broken child rather than a small site.

Every URL in the tree starts ticked. On a site of any size that means clicking Add selected adds hundreds of URLs to a form that will only accept 10 — untick down to the pages you actually want first.

What the scanner will reach

Scan browsers only visit publicly resolvable http/https addresses. Every top-level navigation is checked, including redirects and the login URL used by authenticated scanning, so a public URL that redirects to an internal one is stopped at the redirect.

  • A private, loopback, link-local or otherwise internal address is refused with "That address is not reachable from this service."
  • A hostname that doesn't resolve gives "That host could not be resolved."
  • Credentials embedded in the URL (https://user:pass@host/) are refused outright — use authenticated scanning instead.

To scan something only your own machine can reach — localhost, a staging box on a VPN, an internal admin tool — use the Chrome Toolkit and read the capture in the Workflow Analyzer. It runs in your browser, so it scans whatever your browser can already load.

Browser & OS picker

Scans run on real desktop browsers in macOS and Windows virtual machines on our own hardware — a real browser on a real operating system, not an emulation.

BrowserWindowsmacOS
Chrome✔✔
Firefox✔✔
Safari engine (WebKit)—✔
  • Versions are selectable per browser — pick Latest (the default) or any installed major version. The list comes straight from the fleet, so newly installed versions appear automatically.
  • The default is Chrome · Windows · Latest.
  • Desktop browsers only for now — mobile scanning is on the roadmap.
  • The scan's report records the environment it ran on, e.g. 151.0.7922.34 (Device Farm · Windows 11) — so you always know which browser produced a result.
  • Scheduled re-runs use the same browser choice as the scan they belong to.

API fields: a11yConfig.browser.browserName (chrome | firefox | webkit), a11yConfig.browser.browserVersion (latest, latest-N, or an exact major), a11yConfig.browser.platformName (a platform the picker lists, written exactly as it appears there — note the casing, e.g. Windows 11, MacOS 26).

Scan Settings — Accessibility tab

WCAG version

Pick from the full matrix of WCAG 2.0 / 2.1 / 2.2 at Levels A, AA, or AAA. The default is WCAG 2.1 AA — the most common compliance target.

VersionValue in APICommon target for
WCAG 2.2 AAAwcag22aaaGovernment / high-bar accessibility programs
WCAG 2.2 AAwcag22aaModern corporate standard
WCAG 2.2 Awcag22aBaseline on 2.2
WCAG 2.1 AAwcag21aaRecommended default
WCAG 2.1 Awcag21aMinimum 2.1 conformance
WCAG 2.0 AA / Awcag2aa / wcag2aLegacy compliance programs

Rule toggles

ToggleDefaultEffect
Advanced rulesOnEnable extra axe-core rules that are off by default. Recommended to leave on.
Best practicesOffInclude rules that improve UX but aren't WCAG violations (e.g., heading-order, region).
Needs reviewOnInclude "incomplete" results that need manual verification. Turn off for a pure pass/fail list.

See Rule categories for what's included in each.

Advanced — Page load delay

For sites that hydrate progressively (single-page apps, lazy-loaded above-the-fold content, on-load animations), the scan can wait a fixed number of seconds after navigation before running axe-core. This avoids false positives from elements that haven't rendered yet.

FieldRangeDefaultWhen to bump it
pageLoadDelay (sec)0–302Single-page apps that fetch hero content client-side, pages with intro animations, or sites where you see "expected element missing" issues that you can clearly see in the page snapshot

Setting pageLoadDelay = 0 is fine for traditional server-rendered sites and shaves the scan time. Anything above ~10 seconds is rarely needed and just stretches scan duration.

API field: a11yConfig.pageLoadDelay (integer 0–30).

Scan Settings — Authentication tab

If your pages need credentials to load, flip to the Authentication tab and pick one of Cookies, Login Form, or HTTP Headers. Full configuration: Authenticated Scanning.

What gets captured per URL

For every URL in the scan, the engine records:

  • Accessibility score (0–100)
  • Violations (failures), passes, and incomplete counts
  • Issues by severity (critical / serious / moderate / minor)
  • HTML snapshot of the page as it was scanned — external stylesheets inlined so it renders faithfully, and links and forms disabled so it can't navigate. This is what the report renders when it highlights a failing element; no image screenshot is taken.
  • The browser and OS the scan ran on (e.g. 151.0.7922.34 (Device Farm · Windows 11))

Aggregated across all URLs in the scan you also get:

  • Where you stand — the success criteria for the WCAG version you scanned against (50 for 2.1 A + AA, 55 for 2.2 A + AA), each reported as failing, no problems found, needing a person to decide, or can't be tested by tools
  • Affected-pages table
  • Affected-components table (DOM selectors with issue counts)
  • Overall score

FAQ

Why can I only add 10 URLs? To keep a single scan run bounded. For larger sites, split the pages across several scans — a CSV upload or a sitemap import makes building those lists quicker, but neither raises the cap of 10 URLs in one scan, and neither does the API.

Does the scanner follow links? No. Every URL you want scanned must be in the list.

Do credentials get stored? Login credentials and cookies are encrypted at rest. See Authenticated scanning for details on handling.