Understanding Results
Read a TestKase accessibility scan report — the fix plan, where you stand, coverage, and per-element detail.
Every finished scan opens into a report built around one question: what should you fix, and in what order.
1. Run header
The band at the top carries what changed since the previous run — how many issues were fixed and how many are new — along with the browser and platform the scan actually ran on, the WCAG version it was measured against, and the accessibility score as a supporting figure rather than the headline.
A first run says so rather than showing zeroes.
2. Fix plan
The ranked list of fixes, ordered by how many issues each one clears rather than by severity. One broken component used on six pages is one fix, not forty, so reach decides the order.
Each row names the fault in plain words, how far it reaches, the component responsible for most of it, the severity, and the WCAG criterion the fix satisfies. Expand a row for guidance on fixing it.
Only confirmed problems appear here. Items to check by hand are left out — nobody can be told to fix something the checker was not sure about. Reports saved from the Chrome Toolkit get a fix plan too.
3. Where you stand
Every criterion for your WCAG level, in four boxes that add up to the total:
| Result | What it means |
|---|---|
| Failing | At least one confirmed issue mapped to this criterion. |
| No problems found | An automated rule exists, it ran, and found nothing wrong. |
| Needs a person to decide | A rule ran and could not determine the answer. |
| Can't be tested by tools | No automated rule covers this criterion. It was not tested — a person has to check it. |
Click See list under any number to see which criteria are in that box, each linked to its W3C page.
Which criteria appear follows the version and level the scan targeted — 50 for WCAG 2.1 A + AA, 55 for 2.2 A + AA. See WCAG conformance matrix.
4. What we checked
Pages scanned with their individual scores and issue counts, the browser used, and how many issues your team has hidden.
5. Issue list
Two buttons above the list switch grouping: By Rule (e.g. color-contrast, image-alt) or By WCAG criterion (e.g. 1.1.1 Non-text Content). Two dropdowns filter it, by severity and by category.
Each group shows the rule description, impact, count of matching issues, pages affected, and a roll-up component count.
Items the checker could not decide are not mixed in with the confirmed problems. They sit in a folded section, To check by hand (N), at the bottom of the list.
6. Issue detail panel
Click any issue to open the detail panel:
- Rule description — the human-readable version of the rule.
- How to Fix — the failure summary for this element.
- Impact, WCAG criterion and level, a Tags list, and a link to the W3C reference.
- Target selector — CSS path to the failing element, with a copy button.
- HTML snippet — the exact failing markup, with a copy button.
- Affected Page — the scanned URL the issue came from.
The panel also carries Hide and Report a bug.
7. Page snapshots with element inspection
Each scanned URL stores an HTML snapshot of the page as it was scanned — external stylesheets inlined so it renders faithfully, links and forms disabled so it can't navigate. No image screenshot is taken. Click an issue and the snapshot loads at the top of the detail panel with the failing element outlined in red. Zoom in, Zoom out and Fit are the only controls. See Element inspection.
Hiding issues
Open an issue and use Hide in the detail panel to leave it out of the score — for a false positive, or a risk you have accepted. Unhide puts it back.
Exports
The Export button in the report header offers two formats:
- Export as PDF — the same sections as the screen: run header, fix plan, where you stand, what we checked, then the breakdowns. It does not contain the per-issue detail or the page snapshots.
- Export as CSV — the summary as a spreadsheet: scan metadata, the fix plan, the criteria and their results, and the pages scanned.
A separate scan-run history CSV (score and issue count per run) is available from the Scan history tab. See Export formats.
🚧 Coming soon — a per-issue CSV and a machine-readable JSON export. Today's CSV is a summary export, not one row per issue.
Items to check by hand
Sometimes the checker can't decide if something is a problem. For example, text on top of an image, where the background colour can't be measured. A person needs to look at these.
With the Needs review toggle on (the default), they appear in the To check by hand (N) section at the bottom of the All Issues tab, and the top of the report shows + N items to check by hand. They are not counted as problems, they are kept out of the fix plan, and the conformance section reports their criterion as needs a person to decide rather than as failing. In Website Scanner reports they still lower the score — the one place they are treated like confirmed problems. In Chrome extension reports they do not.
Disable the Needs review toggle at scan time if you want a score built only from machine-confirmed failures. See Rule categories.