Skip to main content

Accessibility Testing

Automated Accessibility Testing: What axe-core Catches and What It Doesn't

Filip RalicOct 16, 20263 min read
Automated Accessibility Testing: What axe-core Catches and What It Doesn't

I've shipped a scan that reported zero violations on a form that was, in practice, unusable by keyboard. The modal it opened trapped focus in the wrong place, cycling between two elements that weren't the ones a user actually needed to reach. No automated rule checking for ARIA attributes was ever going to catch that, because nothing about the markup itself was technically wrong. The experience was still broken.

What automated scanning is genuinely good at

Contrast ratios, missing alt text, unlabeled form fields, misused ARIA attributes, heading structure, focus order as it exists in the DOM. All of this is machine-checkable, and wiring it into CI so a regression here can't land silently is one of the more solved problems in this space. If you're not running this on every PR yet, that's the first, cheapest fix available, and there's genuinely no excuse not to.

What it structurally can't check

Whether tab order matches the order a real keyboard user would expect, beyond just what the DOM order technically is. Whether a screen reader announcement is coherent when read start to finish, not just present. Whether a custom component's interaction pattern makes sense to someone who can't see it. Automated tools verify that an ARIA attribute exists and is spelled correctly. They have no way to verify that the experience the attribute is supposed to enable actually holds together.

The manual pass that still has to happen

A real screen reader walkthrough, done by someone who tests this way regularly and knows what a coherent flow sounds like versus one that's technically compliant and practically confusing, catches an entirely different category of bug than a scan does. These two methods aren't redundant with each other. They're checking different things, and treating a clean automated scan as proof the manual pass isn't needed is the mistake I see most often.

Where the two fit together

Automated checks as a regression gate, catching the cheap, common, easily-missed mistakes on every change. A scheduled manual pass, on new flows and before major releases, for the part that requires an actual human using an actual assistive technology. Neither one covers for the other, and a team running only the first has usually convinced itself it's further along than it is. We go into the fuller checklist, beyond what a scanner covers, in accessibility testing past the checklist, and this is the gap our accessibility testing service is built to close.