Seodar

Accessibility

The failures a machine can prove, in the scan you already run

axe-core against WCAG 2.2 A and AA on a rendered sample, in the same crawl - the slice a machine can prove.

What automated testing can and cannot reach

This is the first thing on the page rather than a caveat at the bottom, because every honest claim below depends on it.

Machines can prove it

  • Contrast below the required ratio
  • A form control with no label
  • A heading order that skips a level
  • An image with no alt attribute at all

A person has to judge it

  • Whether the alt text describes the image
  • Whether the keyboard path makes sense
  • Whether an error explains what to do
  • Whether the reading order matches the visual one

On the page a person actually sees

A contrast ratio is a property of rendered pixels. A missing label is a property of the accessibility tree. Neither exists in raw HTML, so an accessibility check that reads markup is measuring something adjacent to the question.

The audit runs in the same headless browser the crawler already uses for rendering, against the page after JavaScript has run - which is the only version anybody is using.

Where a contrast failure exists
In the HTML sourceno colour, no computed style, nothing to measure
In the rendered pagea ratio of 3.1:1 against a required 4.5:1

A sample, chosen by template rather than by traffic

Accessibility failures are overwhelmingly template failures. A contrast problem in a card component is on every page that uses the card, and auditing twenty product pages finds it twenty times instead of finding the twenty other things.

So the sample takes one page per URL shape before it takes a second of anything, home page first. Every scan records what it audited out of what was eligible, because a sample presented as a survey is the same lie as a survey that was really a sample.

Two ways to spend the same 20 audits
By traffic1 distinct problem

20 product pages

By template12 distinct problems

home, blog, product, category, search, account…

An illustration of the reasoning, not a measurement - the ratio depends entirely on the site. The rule it comes from does not: a template failure repeats on every page built from that template.

What this is not

It is not an accessibility audit. An audit is a person using the site with the assistive technology your visitors use, and it finds the things that matter most - a focus order that makes no sense, an error message that says “invalid input”, alt text reading “image1.png”.

It is not a compliance certificate and there is no such thing from any tool. What it is: the failures a machine can prove, found early, on every scan, for free - so the audit you eventually commission starts from a site that has already fixed the mechanical ones.

What a finding carries

  • The WCAG criterion

    Which success criterion it comes from and at what level, so a finding can be looked up rather than taken on trust.

  • The element

    The selector it was found on, and the page it was found on - not a count with nowhere to go.

  • Its own category

    Scored in a category with its own cap, so accessibility cannot drown the technical findings and cannot be drowned by them.

  • What was not audited

    How many pages were sampled out of how many were eligible, on every scan.

Questions

No, and no tool can. A scan reaches 25 of the 55 success criteria at A and AA - the ones with an unambiguous machine test, like contrast ratios, missing labels, a focus ring that does not exist. The other 30 need a person: whether alt text describes the image, whether the reading order matches the visual one, whether an error message is understandable. The panel lists both sets by number, so what was not tested is as visible as what was.
A sample, and every scan records how many it audited out of how many were eligible. The sample is chosen for template diversity rather than by traffic - one page per URL shape finds more distinct problems than twenty copies of the busiest page, because a template failure repeats on every page built from it.
Yes, in its own category and with its own cap, so an accessibility problem cannot drown the technical findings or be drowned by them. Each finding carries the WCAG criterion it comes from and the element it was found on.
Partly because the same rendered page is already loaded - running axe against it costs one extra step rather than one extra product. Partly because the overlap is real: headings that carry structure, images that carry text, and pages a machine can parse are the same requirement written twice. And partly because in Europe the BFSG made it a legal question for a lot of sites that had never asked it.
axe-core 4.10.2, pinned by digest at build time, run against the tags for WCAG 2.0, 2.1 and 2.2 at levels A and AA. The version is pinned rather than floating because a rule set that changes under you turns a clean scan into a regression nobody made.

Start free

One site and 100 credits - up to 200 pages a scan, about 5 scans, and the whole report. No card. Paid plans add more sites, bigger crawls and the AI rewrites.