Understanding Your Accessibility Report

An accessibility report tells you where people are likely to struggle with your page — text they cannot read, controls they cannot reach with a keyboard, buttons a screen reader announces as “button” and nothing else.

The report is organised so you can start at the top and stop whenever you run out of time. The findings are ordered by how much they affect real use, so the first few are always worth more than the last few.

Two things are worth knowing before you read a single number.

• A finding is a place to look, not a verdict. Every one names the element it found, what it measured, and what would fix it. If a finding looks wrong, the element it names is the fastest way to check.
• Nothing here is a legal conformance claim. Automated testing finds real problems quickly, but it cannot certify a page. Section 10 is honest about where the line is.

The score is a summary of everything found, weighted so that severity and reach both matter. A critical problem affecting many elements moves it a long way. A minor problem on one element barely moves it at all.

It is deliberately hard to score highly. A page with a couple of serious issues lands in the seventies rather than the nineties, because a couple of serious issues is genuinely something to fix. If you are comparing against a tool that reports 100, see section 9 — that difference is usually real and explainable.

Use it as a trend, not a target

The score is most useful watched over time on the same page. Chasing the number itself leads to bad decisions — hiding an element from assistive technology, for instance, removes the finding and makes the page worse. The findings are the substance; the score is the summary.

One consequence worth understanding: a score can go down when you have improved a page. Fixing a component so that content becomes visible can expose text that was never checked before. That is the report becoming more accurate, not the page becoming worse.

The overall figure is made from several areas. They are not weighted equally — accessibility and colour contrast together account for more than a third of it, because they affect the most people most directly.

An area with nothing to measure is left out, not scored zero. A page with no images is not penalised for media; that area is dropped and the rest carry the weight between them. If you see Not scored, it means there was nothing to look at — which is different from failing, and the report keeps the two apart.

Two caveats about specific areas, so you read them for what they are. Security is a checklist of whether protective headers are present, not a judgement of how good they are. Reliability reflects only the links that were actually checked — a clean result with nothing checked looks the same as a clean result with everything checked, so read the count beside it.

Every finding carries a severity. It describes the effect on someone using the page, not how hard the fix is.

Count the causes, not the findings

A number like “84 findings” is almost always fewer real problems than it sounds. One button component used in twelve places produces twelve findings and needs one fix. Sort by the rule rather than by the element and the list usually collapses to a handful of causes.

This is why the biggest score improvements tend to come from shared components — a header, a card, a form control. Fixing one of those often moves more than a day spent on individual pages.

Individual checks resolve to one of four states, and the difference between the last two is where most misreadings happen.

Why “needs review” is counted

Some tools quietly treat an undecided check as a pass. We do not, because “we could not tell” is not evidence that something is fine. It affects the score less than a definite failure does, but it is not free. If a page has many of these, the honest reading is that a meaningful part of it has not actually been assessed yet.

Why “not tested” is never a pass

Roughly a sixth of the WCAG criteria we list cannot be checked automatically by anyone. They appear as Not tested and are excluded from the totals entirely — they are not counted as passes and they do not drag the score down. Counting them as passes would let a page that has never been examined look perfect.

The conformance table is separate from the score and answers a different question. The score asks “how is this page doing?” The table asks “does this page meet each specific WCAG requirement?” They will not agree, and they are not meant to.

Requirements come in levels. Level A is the minimum — failing one usually means some people cannot use the content at all. Level AA is what almost every legal and procurement regime actually requires, and it is the level to aim for. Level AAA is the highest; W3C does not recommend it as a blanket policy because it is not achievable for all content. We test AAA requirements and show you the results, but they never count against your score.

Conformance is all or nothing

A page meets Level AA when no Level A requirement fails and no Level AA requirement fails. One failure anywhere denies the claim. This is why a page can score respectably and still not conform — and why the single most useful column in the table is the list of failures, not the total.

This table is shaped to match a VPAT, the format most procurement processes ask for, so it can be handed to a reviewer directly. It is evidence to support a claim — it is not the claim itself.

Contrast is measured from what your page actually paints, not from your stylesheet. If a colour is semi-transparent, it is blended with whatever sits behind it first, because that blend is what a reader sees.

When we decline to give a number

If text sits on a gradient, a photograph or a video, there is no single background colour, so any ratio would be invented. Those come back as needs review. The honest fix is usually to put a solid panel behind the text rather than to find a colour that happens to work over one part of the image.

Only text people can see

We check elements that actually render text. Empty layout containers, decorative bars and hidden controls are skipped — a colour pair that is never painted anywhere is not a real problem, and reporting it would bury the ones that are.

The suggested colour

Every failing pair comes with a suggestion. It keeps your hue and adjusts lightness only, so the result still looks like your brand rather than collapsing to black or white. You are free to pick a different colour — the ratio is what matters, not our suggestion.

You may also see an APCA figure beside the ratio. It models perceived contrast more accurately, especially on dark backgrounds and thin type, and it is useful for judgement calls. It is not part of any conformance requirement, so it never affects your score.

A practical order of work, roughly by value returned.

1. Group by cause

Sort the findings by rule rather than by element. A long list usually collapses into a few shared components, and each component is one fix.

2. Start with anything that blocks a task

Controls with no accessible name, form fields with no label, keyboard traps. Someone using a screen reader or a keyboard alone cannot get past these, and they are typically small fixes.

3. Then contrast, from the most-used component down

Contrast problems are usually a token or a theme decision rather than a per-page mistake. Fix the token and a long list often clears at once. Check both light and dark themes — a colour that works on one frequently fails on the other, in the opposite direction.

4. Then structure

Headings in a sensible order, landmarks around the main regions, lists marked up as lists. This is how people using assistive technology navigate; without it they read everything from the top, every time.

5. Then work through “needs review”

These need a person, and they are the ones that turn an automated pass into an honest one. Text over imagery, whether an animation can be paused, whether focus order still makes sense visually.

Check it with the page, not the report

The fastest sanity check on any finding is the page itself. Tab through it without touching the mouse: you should always be able to see where you are, and you should never get stuck. That one exercise finds more real problems than any number in this report.

If another tool scores your page 100 and this one does not, both can be right. They are not measuring the same things.

Compare findings, not scores. Two tools reporting different numbers tells you nothing. Two tools disagreeing about whether a specific element fails a specific requirement is worth ten minutes — and it is always settled by looking at the element itself.

Being clear about this protects you, because an automated pass is not a defence.

• Testing can prove a failure. It rarely proves success. A clean report means nothing automatic was found, not that the page works for everyone.
• Some requirements need a person. Whether reading order makes sense, whether instructions rely on shape or position, whether navigation is consistent across a site. No tool decides these.
• A passing check is not a good experience. An accessible name can be present and useless — “click here” passes the check and helps nobody. A heading order can be valid and meaningless.
• One page is not a site. Results describe the page that was scanned. Templates share components, so findings usually generalise, but the scan does not.
• Sampling has limits. Where the report says something was sampled, it describes what was inspected, not everything on the page.

The strongest thing this report gives you is a short, specific, evidence-backed list of things that are definitely wrong. That is genuinely valuable, and it is not the same as a certificate.

For a conformance claim you can stand behind — a public accessibility statement, a procurement response, a legal requirement — you need manual expert review as well. Use this report to clear the automatable problems first, so that review can spend its time on the things only a person can judge.

My score dropped and I did not change anything.

Usually the page changed underneath it: new content, a third-party embed, an A/B variant, or an ad. It can also happen after a fix that made hidden content visible — content that is now checked for the first time. Compare the finding lists rather than the numbers.

Can I get to 100?

On a simple page, yes. On a rich one it is harder, and chasing it is usually the wrong goal. A page in the nineties with a short list of reviewed, understood exceptions is in better shape than one that reached 100 by hiding things from assistive technology.

A finding looks wrong to me.

Check the element it names. Each finding tells you what was measured and where, so it is quick to verify. If it is genuinely wrong we want to know — a false finding costs you trust in every other finding.

Do I have to fix everything?

Fix what blocks people first: critical and serious findings, then contrast, then structure. Minor findings are worth clearing when you are already working in that area. A short list of known, accepted exceptions is a perfectly respectable position.

Does a good score protect me legally?

No. It is useful evidence that you have done the work, and it is not a certification. Regulations generally reference WCAG conformance, which needs manual review as well.

Which page should I scan first?

The one most people land on, and the one that completes your most important task — sign-up, checkout, contact. Fixing shared components on those two usually improves every other page at the same time.