How to read an accessibility report.

Start with what was tested, then decide what needs a fix and what needs a person. A scan result is one part of your assessment, not the whole verdict on a website.

Published September 25, 2026 · By GatekeeperQA

Open the sample report alongside this guide, or download the sample PDF.

1. Check coverage before the score

Confirm the page URLs, scan date, completed pages and execution errors. A URL identifies a page, but not every state of that page: an open dialog, form error or expanded menu may need a separate test. GatekeeperQA’s public scanner checks the initially loaded page state.

INCOMPLETE is a coverage warning. If a page could not be assessed, zero reported findings does not mean it passed. Read the recorded error, resolve the cause where possible and repeat the scan. Keep completed-page evidence, but state what remains untested.

2. Read the quality gate in context

PASS: the automated result met the configured policy. It does not establish complete accessibility.
WARN: review the warning and the policy that produced it before deciding the next action.
FAIL: inspect the threshold explanation and the findings that exceeded it.

For example, a policy allowing zero critical findings fails when one is found. That is a release-policy decision. It is different from a manual assessment of all applicable requirements. Reviewer notes and tracking statuses do not rewrite the original automated result.

3. Inspect the finding, not just its severity

Use severity to help prioritize, then consider the barrier in the actual user journey. A problem that prevents submitting an important form may need urgent attention even when other issues have similar labels. Severity labels are not WCAG conformance levels.

Read the rule, page, selector, captured HTML and available measurements together. A selector locates a rendered element; it is not a source-file line number. Report counts may include the same element under more than one rule, so do not treat their sum as a count of unique affected elements.

Example: an unnamed button

<button id="checkout"></button>

In this fictional example, the button-name finding points to #checkout. Investigate the button’s purpose and accessible name. A visible “Checkout” label can address this example; verify the actual component and interaction before closing the issue.

4. Treat “needs manual review” as unresolved

An automated check may be unable to reach a decision, for example when text sits over an image. That is neither a confirmed defect nor a pass. Inspect the captured evidence and test the rendered page in the relevant state.

If a contrast finding includes measured foreground and background colors, a ratio and a required ratio, use those details to reproduce it. When measurements are unavailable, do not invent them. Record the background, text styling, method and outcome of your manual check.

Also plan keyboard, focus, zoom/reflow and assistive-technology testing appropriate to the feature. A scanner’s manual-review items are not an exhaustive manual test plan. W3C explains why knowledgeable human evaluation remains necessary.

5. Turn evidence into a reproducible ticket

Give the developer enough context to find the barrier and check the change:

Page URL, date, browser and page state.
Rule, affected element selector and HTML snippet when available.
Steps to reproduce and the observed impact.
Expected behavior, supporting evidence and relevant rule guidance.
Suggested fix to investigate and an explicit retest step.

Keep credentials and personal data out of shared tickets. GatekeeperQA’s copy-issue text and CSV exports help with handoff; copying into a tracker is not a direct integration.

6. Verify the same scope after the fix

Repeat the scan on the same URLs and manually exercise the relevant states. A finding that is no longer detected may have been fixed, moved or removed from the tested state. Confirm that the element still exists and that its behavior works before marking the issue verified.

Keep the original report, the retest and reviewer evidence together. Download reports you need to retain beyond the account’s retention window.

A quick review before you share

Does the report identify what was tested and what was not?
Are confirmed findings separate from unresolved manual checks?
Can another tester reproduce each reported barrier?
Does each verified fix have dated retest evidence?

Scan a page

Next: follow the complete scan-to-retest workflow or review scanner coverage and usage limits.