TestKase
TestKase
|Docs
Accessibility TestingReference

Troubleshooting

Common scan failures, auth errors, and report-display issues — and how to resolve them.

Start with the scan row's status message. It usually explains the problem in one line. If not, these are the most common causes.

A scan says Pending

Check first whether the scan has a schedule. If it does, Pending is normal and permanent, not a fault.

A scan created with its schedule already switched on does not run when you save it — it waits for its first slot. Its own status is set to pending and stays there for the scan's whole life; only the runs underneath it ever complete. Once it has run at least once, the row shows that run's result instead, together with a line reading Daily · … · next … · Run #N. Before its first slot the row reads Pending with not run yet.

Two consequences:

  • Run scan is greyed out on anything Pending, so you cannot force a scheduled scan to run early. If you want a result now and a recurring one, create the scan without a schedule, then add the schedule with Edit configuration → Schedule.
  • A scan whose row still says Pending long after its next-run time has passed is a real problem. The usual cause is an earlier run wedged in Running, which holds that scan's schedule — open Scan history and check whether the last run ever finished.

A scan with no schedule should never sit at Pending. Those start immediately, so a manual scan stuck there means the run never started (for example an API restart between the row being created and the browser being launched). Re-run it from the row's Run scan action; if that also pends, open a support ticket with the scan ID.

Scan completed with zero issues (and you expected some)

  • Authentication may have failed. The scanner was served a login page instead of your app. Verify cookies / form selectors / headers. See Authenticated scanning.
  • The page is empty or a loading shell. If your app renders content after a JS fetch, the scanner may have captured the skeleton. Rendering waits are generous but not unlimited.
  • Rule pack is too narrow. If you disabled Advanced rules or Needs review, you may have filtered out real issues.

My score dropped and nothing changed

Two things move a score with no change to your site, so rule them out first: a needs-review difference (below), and someone hiding or un-hiding an issue — the score is recalculated every time the report is opened, so a hidden issue changes the number without a re-scan. See Hiding an issue.

Check the needs a person to decide count in the Where you stand section of the Summary tab, and the To check by hand (N) section at the bottom of the All Issues tab. These are items the checker could not decide. In Website Scanner reports they still lower the score like confirmed problems, even though the report lists them separately. A page that renders slightly differently between runs can produce more of them. See Rule categories.

Scan failed

A scan is marked failed only when every URL fails. If some pages loaded, the scan completes with the message Scan completed with N unreachable URL(s): … and reports on the pages that did load.

Typical messages:

  • Domain not found — the URL could not be resolved / Connection refused — the server is not responding — check the URL and that the host is reachable from the public internet.
  • Connection timed out — the server took too long to respond — usually a heavy SPA. Pre-warm the page or reduce start-up JS.
  • SSL/certificate error — the site has an invalid certificate.
  • Request blocked — the site may be blocking automated access — bot protection or a WAF.
  • Connection reset — the server unexpectedly closed the connection.
  • Too many redirects — the URL causes a redirect loop.
  • Empty response — the server returned no data.
  • URL returned HTTP 4xx/5xx.
  • That address is not reachable from this service. — the URL resolved to a private or internal address and was refused for security. Use the Chrome Toolkit for internal URLs.
  • Scans can only run in your primary organization for now.
  • Accessibility scans run on real browsers. You need a Live Browser plan (or remaining free minutes) to run them. / Scheduled accessibility scans are automation. You need an Automate plan (or remaining free minutes) to schedule them.

Authentication problems produce no distinct message — a failed login usually shows up as a scan that completed with few or no issues (see "Scan completed with zero issues" above).

I turned on Advanced rules but the issues I expected aren't there

Findings are filtered against the WCAG version and level you chose before they reach the report, and most Advanced rules — every landmark-* rule, region, skip-link, focus-order-semantics, accesskeys — carry only axe's best-practice tag. On a WCAG 2.1 AA scan with Best practices off, their failures are discarded. Turn Best practices on as well. See Rule categories.

An older scan or an older run has disappeared

Accessibility scans are removed once they pass the retention window — the scan, its runs, its issues and its page snapshots all go, not just the files. Export anything you need to keep as a PDF or CSV before then. See Scan limits.

Consolidate or Compare won't open

  • "Scan «name» is not completed" — consolidation only accepts completed scans. Wait for the run to finish, or drop that scan from the selection.
  • Compare needs exactly two runs of the same scan, picked from that scan's History tab. It cannot compare two different scans — use Consolidate reports for that.
  • Consolidation needs at least two scans selected in the Website Scanner list.

I can't open a report someone shared

Only the scan's creator and members of a team the scan is shared with can open a report.

Ask the creator to share it with a team you belong to. Note that the creator can only share with teams the creator is also a member of, and only the creator can share or unshare — a teammate who can see the report cannot pass it on.

There is no public link to fall back on: a recipient must have a TestKase account in the same organization and be in one of the scan's teams. If access vanished, the most likely cause is that the creator unshared the team or the team was deleted — neither sends a notification. See Sharing scans.

Chrome Toolkit panel doesn't appear

  • DevTools must be open. The panel lives inside DevTools. Open DevTools (F12) on the website you want to test, then click the Testkase Accessibility Toolkit tab.
  • Don't see the tab? Click » at the top of DevTools to see more tabs.
  • If DevTools was already open when you installed, close and reopen DevTools.
  • Click the toolkit's icon in the Chrome toolbar to see these steps. It shows a red warning if you are on a page where Chrome blocks extensions.
  • Ensure you're on a Chromium-based browser (Chrome / Edge / Brave / Arc). This applies to the Toolkit only — Website Scanner scans run on Device Farm browsers and don't depend on your local browser.

Chrome Toolkit can't scan a page

If the toolkit can't read a page, the panel shows a message that says why. Try these in order:

  • You are on a Chrome page (chrome://…) or the Chrome Web Store. Chrome does not let extensions run there. Open the website you want to test instead.
  • Reload the page and scan again.
  • Open chrome://extensions, click Details on Testkase Accessibility Toolkit, and set Site access to On all sites.

Chrome shows "started debugging this browser"

While the toolkit panel is open, Chrome shows a bar: "'Testkase Accessibility Toolkit' started debugging this browser". This is expected. The toolkit needs it to check the page. Don't click Cancel.

The scan report mentions a certificate problem

Scans run in a brand-new browser each time, so it checks your certificate from scratch — no cached intermediates, no previously-accepted exceptions. That catches faults your own browser silently tolerates: an incomplete chain, a self-signed staging certificate, or one issued for a different hostname.

The scan is not blocked by this — it runs and reports normally, with a note naming the host and the fault. Fixing it is still worthwhile, because a first-time visitor's browser sees exactly what ours did.

Element highlight doesn't line up with the page

The element-inspection overlay draws on the page snapshot, not the live page. If you've changed the page since the scan, re-run the scan to get a fresh snapshot. If the failing element's selector no longer matches anything inside the snapshot, no outline is drawn at all.

A shared report shows no page snapshot

Page snapshots are creator-only. The report itself — summary, conformance matrix, issue list, issue detail — opens for every member of a team the scan is shared with, but the snapshot request checks that you created the scan and answers "Scan not found" to anyone else, so the panel simply has no snapshot and no red outline. Ask the scan's creator to look at the element in context, or run your own scan of the same URL.

Exports disabled

All export formats are included for every account — there is no plan gate on exporting. If an export fails, retry, and if it keeps failing, contact support with the scan ID.

Two things are gated, and they are the limits customers usually hit: running a scan needs a Live Browser plan (or remaining free minutes), and scheduling one needs an Automate plan (or remaining free minutes).

PDF export works on Website Scanner reports only. A report saved from the Chrome Toolkit still shows Export as PDF in its Export menu, but that item is wired to the Website Scanner's route — it will fail, or hand you a different Website Scanner report of your own with the same id. Export those as CSV. See Export formats.

Still stuck?

  • Check the reference pages for concept-level clarification.
  • Open a support ticket from the in-app help menu — include the scan ID (visible in the URL on the report page).