How to read accessibility findings

Codes starting with A11Y- come from the accessibility module. Unlike the rest of the audit's findings, we did not invent them. They are rules from axe-core, the open-source engine most widely used in the field, which walks the page in a browser looking for violations of specific criteria.

That is why this manual has no page per code for them. The axe authors maintain their own continuously updated description of every rule, and our copy would be worse and would go stale. Every such finding in the report links straight to the official description.

What that documentation will not give you is how to read the findings. This is the missing part.

A finding on one page almost never means one page

This is by far the most important sentence on this page. The audit walks a sample of your site, but the same defect usually does not sit on one URL, but in a template. The header, the footer, a product card, a form, a navigation component.

The practical consequence: when the report shows A11Y-color-contrast on five pages, do not fix five pages. Look at what they have in common. A footer button with insufficient contrast is one line of CSS and a thousand pages fixed at once.

The reverse holds too, and it is fair to say: the absence of a finding does not mean the site is fine. A sample is a sample. A template we never hit went unexamined.

What levels A, AA and AAA mean

The rules map onto criteria of the WCAG standard (Web Content Accessibility Guidelines) from the W3C. Those come in three levels of stringency:

In practice: the goal is not „meet everything". The goal is level AA. Two separate European directives require it, and they are often merged into one: 2016/2102 for public sector websites and 2019/882 (the EAA) for many commercial services, enforceable since 28 June 2025. Both point to the standard EN 301 549, and here is a detail worth getting right: the reference version is still v3.2.1, which is built on WCAG 2.1, not 2.2. Version v4.1.1, which adopts WCAG 2.2, was published on 2 September 2026, but it becomes binding only once the Commission cites it in the Official Journal of the EU. So what is enforceable today is AA under WCAG 2.1; criteria added only in 2.2 are not among them. That is why we show you three numbers side by side (under WCAG 2.0, 2.1 and 2.2) instead of merging them into one: each matches a different rule, and the headline „Accessibility score" is the WCAG 2.1 AA row. Fix level A findings first and treat AAA as a bonus.

What an automated test cannot find

This is a limit to understand before anyone mistakes a green result for an accessible site. An automated test catches only part of the real problems, namely those judgeable from markup and styles. Exactly how much depends on what you count, and the figures diverge more than is usually admitted: the field commonly cites 20–30%, which is the share of WCAG success criteria that can be checked by machine. Deque, across 13,000 pages and nearly 300,000 issues, measured 57%, but it counted the volume of issues found, not criteria, and it is the vendor of axe, the very tool we use. Both numbers are true; each measures something different. What matters is what they share: the rest needs a person.

• Whether the alternative text makes sense. alt="image" passes as filled in. That it helps nobody is something only a person can tell.
• Whether the tab order is logical. A tool verifies that elements can be reached; whether the path makes sense, it cannot.
• Whether video captions match the audio.
• Whether a form explains, intelligibly, what the user got wrong.
• Whether the site can be operated by keyboard from end to end. You find that out by putting the mouse aside and trying.

So zero findings means „nothing tripped what we can measure", not „the site is accessible". We say so plainly, because the opposite would be the most expensive untruth in the whole report.

We measure at two window widths: 1280 px and 390 px. That is not a detail, because some problems exist in only one of the layouts. A typical case is a horizontally scrollable table that keyboard users cannot reach on a phone: on a wide screen it fits and there is nothing to report, on a narrow one it becomes a scrollable region a keyboard cannot operate. So a finding you see may not reproduce on your monitor; try narrowing the window.

What order to fix them in

When there are many findings, a simple rule helps: go by what actually blocks somebody, not by the number of occurrences.

1. Anything that makes a task impossible to finish. A form that cannot be submitted by keyboard, a basket with unlabelled fields, a login with no accessible error message.
2. Missing text alternatives on content images and links. Here information is lost, not comfort.
3. Colour contrast. It affects everybody who has ever had sun on their screen, that is, everybody.
4. Heading structure and page landmarks. That is how a screen reader user moves around a page (related to our own STR-01).
5. The rest.

And a closing note, because technical audits tend to forget it: accessibility is not about a standard, it is about people. Alternative text, contrast and keyboard operation are the only things in this entire audit that you owe to specific visitors rather than to an algorithm. The rest of the report is about how machines understand you.