We planted 15 accessibility defects in a storefront. axe-core found 4 of them.

Nexaaly · 31 July 2026 · 6 min read

Nearly every free accessibility checker on the web runs the same engine: axe-core. It is good software, it is open source, and it is the honest floor of this industry.

It also cannot see the failure that matters most.

We built a realistic Danish webshop product page and planted fifteen accessibility defects in it — the ordinary kind you find on real sites, not exotic ones. Then we ran axe-core against it, and then our own engine.

The numbers

The eight axe missed are the ones that decide whether someone can buy from you.

The one that matters

Here is the “Add to cart” button:

<div class="buy" onclick="addToCart()">Add to cart</div>

It looks like a button. It is styled like a button. Clicking it works.

It is a <div>. It is not in the tab order, it has no role, and it does not respond to Enter or Space. A keyboard-only or screen-reader user cannot buy the product — not “with difficulty”, at all.

axe-core scored that page as passing its keyboard checks. That is not a bug in axe: detecting this requires evaluating computed styles, event handlers and focusability together, which is outside what a rules engine over the accessibility tree does.

Our engine flags it because it asks a different question — does this look interactive to a sighted user while being unreachable to everyone else?

The regulator is looking at exactly this

The Dutch regulator (ACM) has published what it most often finds wrong in webshops. Its most-cited failure is order buttons and form elements that cannot be operated by keyboard. In France, the first European Accessibility Act lawsuits — emergency injunctions filed in November 2025 against four named retailers — target checkout flows.

So we built a fixture of the ACM’s five most-cited failures and ran both engines at it:

The last row is worth explaining. An error message under a field — red text, plainly visible — with no aria-describedby or aria-errormessage linking it to the input. A sighted user sees the problem. A screen-reader user hears nothing at all and cannot work out why the form will not submit.

Neither axe-core nor Lighthouse detects it. We built that check because the regulator named it, and it took an afternoon.

Three honest caveats

1. This is not a claim that axe-core is bad

It is the industry baseline for good reason, it is in our own stack, and if all you need is detection you should use it — for free — rather than pay anyone.

2. Automated testing finds a minority of WCAG issues

Commonly cited figures run 25–50%. No tool makes a site compliant, ours included. Manual keyboard and screen-reader testing, and testing with disabled people, is where the rest lives. Anyone selling you certainty from a scan is selling you something they do not have.

3. We are still verifying the regulatory figures

The enforcement numbers above come from published summaries, and we are checking them against ACM and the French court records directly. We would rather say that than quote a number we have not verified.

Reproduce it in thirty seconds

You do not need our tool, or any tool.

Open your own checkout and try to complete a purchase without touching your mouse. Tab, Enter, Space only.

Most people who try it are surprised.

We fix what we find, and send the fix as a pull request you review and merge — not a report you have to implement. But the keyboard test above is free, takes half a minute, and you should run it whether or not you ever talk to us.