How to read an accessibility scan report (and what to fix first)

Updated 2026-10-24 · Altlark guides

An automated accessibility scan gives you a lot of information at once: a score, counts, WCAG numbers, CSS selectors and chunks of HTML. This guide walks through an Altlark report section by section, explains what each part means, and suggests an order for fixing things. Most of it applies to reports from other automated tools too.

The header: what was scanned, and when

At the top you'll see the host name, the date and time of the scan (in UTC) and how many pages were scanned. A free scan checks one page. Monitoring scans crawl up to 100 pages per site, following links on the same site, so the report covers templates you might not think to check, like the blog archive or a contact page.

Always note the date. Websites change. A report is a snapshot of the HTML your server sent at that moment.

The score

The score runs from 0 to 100. Altlark starts at 100 and subtracts a penalty for each type of issue found. Errors weigh more than warnings, more instances count for more, and the penalty for any one check is capped, so a single repeated pattern (like 30 social icons with no name) can't take the score to zero on its own. On multi-page scans, the penalty is per page, so a large site isn't punished for being large.

How to use it:

• Track it over time. It's most useful for spotting regressions ("the score dropped after the redesign").
• Don't treat it as a pass mark. A score of 100 means these automated checks found nothing. It doesn't mean the site is accessible, and it says nothing about color contrast, keyboard access or content quality.
• Don't compare scores across tools. Every tool weighs things differently.

Errors vs warnings

Errors are issues that are very likely to block or confuse someone, such as a link with no name or a form field with no label. Warnings are things that often indicate a problem but depend on context: skipped heading levels, "read more" links, autoplaying media, and pages with no h1 or several h1s. Fix errors first.

Issue sections

Issues are grouped by check, errors first, then by how often each appears. Each section shows:

• The title (for example "Form field with no label") and the count.
• The WCAG reference, such as "1.3.1 / 3.3.2 Labels or Instructions (A)". The number is the success criterion; the letter is its level. Search "WCAG 2.2 understanding 3.3.2" to read the W3C explanation.
• The fix, in one line.
• A table of instances: the page path, the element's CSS selector, and an HTML snippet. Up to 50 rows are shown per check.

Using selectors and snippets

The selector is a structural path like html > body > footer > div:nth-of-type(2) > a:nth-of-type(3), or a shorter one like input#email or form#contact > label > input when the element or one of its parents has a unique id. Paste it into your browser's dev tools (in the Console: document.querySelector("html > body > footer > div:nth-of-type(2) > a:nth-of-type(3)")) to highlight the exact element on the live page.

The snippet is the start of the element's HTML, for example:

<a href="https://facebook.com/acme" class="social-icon"><i class="fab fa-facebook-f"></i></a>

Search your theme or templates for a distinctive part of it, like social-icon or fa-facebook-f. Often one template fix clears dozens of instances across every page.

The fix for that example, made once in the footer template:

<a href="https://facebook.com/acme" class="social-icon" aria-label="Acme on Facebook"><i class="fab fa-facebook-f" aria-hidden="true"></i></a>

Notes on issues

Some issues include a note, such as "Has a placeholder, which isn't a reliable label" on a form field, "h2 is followed by h4" on a heading, or "id="email" appears 2 times" on a duplicate id. These tell you why it was flagged and usually point at the fix.

False positives and what the scan can't see

Altlark reads the HTML your server sends, without running JavaScript. That leads to two kinds of mistakes:

• False positives: an icon link that gets its name from a script after load may be reported as empty. Check the element's computed accessible name in your browser's dev tools (Accessibility pane). If it has a good name, you can ignore the issue, though putting the name in the HTML is more robust.
• Missed issues: content added by JavaScript (chat widgets, cookie banners, some booking forms) isn't scanned. Neither are color contrast, keyboard focus, captions or the quality of alt text.

This is why every report carries the same disclaimer: automated checks find some, not all, accessibility issues.

What to fix first

A practical order that gets the most benefit for the least work:

1. Sitewide template issues: missing page language, empty links and buttons in the header or footer, the logo link. One fix, every page.
2. Your key tasks: form labels and buttons on contact, booking, signup and checkout pages. These are where an issue can stop someone completely.
3. Images that carry information: product photos, infographics, banners with text.
4. Warnings: headings, vague link text, autoplay.
5. Manual checks: keyboard-only pass, zoom to 200%, a short screen-reader test.

Then re-scan to confirm the count went down.

Sharing the report

Report links are private but unguessable: anyone with the link can view it. You can print any report to PDF from your browser (the print layout hides navigation and forms). Agencies on a monitoring plan can show their own name at the top of client reports; see white-label accessibility reports for agencies.

Checklist

1. Run the free scan on one page.
2. Read the errors, starting with the biggest sections.
3. Use selectors to find each element; search templates using snippets.
4. Fix templates first, then key forms.
5. Re-scan, then do the manual checks the scan can't.