2026-05-17 · 5 min read

Axe-core catches 57% of WCAG issues. Here is what happens to the other 43%.

The 57% Problem

Axe-core's own maintainers report it finds an average of 57% of WCAG issues automatically ^[1]. That statistic gets repeated often—usually as reassurance. "Automated scanning catches more than half." The problem is what happens to the other 43%.

We run accessibility audits across dozens of sites every month. We deploy axe-core. We layer in manual review. And we watch the gap widen. A scanner is a filter, not a verdict. The W3C is explicit: no tool alone can determine if a site meets accessibility standards ^[4]. We've also seen automated tools produce false or misleading results ^[5]. When we audit, we treat automation as a starting point. Everything else depends on human judgment, intentionality, and patience.

The stakes are real. WebAIM scanned the top million websites and found 95.9% of home pages had detected WCAG 2 failures ^[2]. That number should land hard. It means accessibility failure is the norm, not the exception. The tools we lean on—even the best ones—are not enough to close the gap alone.

What Axe-Core Catches Well

We don't say axe-core is broken. It's the most widely deployed accessibility scanner in the industry for a reason. It runs fast. It integrates into CI/CD. It catches structural markup problems, ARIA misuse, form field labeling, link text, heading hierarchies. These are detectable patterns. The DOM is explicit. The rules are unambiguous.

Our teams use axe-core in nearly every project kickoff. We run it early, fix the findings, move on to the hard part: the stuff that requires thought.

Where the 43% Gap Lives

We've watched axe-core flag some violations correctly and miss others entirely. In our audits, we see consistent patterns in what gets caught and what doesn't. Low-contrast text appears on 83.9% of home pages. Missing alt text, 53.1%. Missing form labels, 51%. Empty links, 46.3%. Empty buttons, 30.6%. Missing document language, 13.5% ^[3].

The chart above shows the top WCAG failures WebAIM found across the top million websites ^[3]. Notice that low contrast dominates. But here's the tension: axe-core can catch some of these patterns. It flags completely missing alt text, missing labels, empty links. But it cannot catch the issues that matter most in practice—the ones where the code is technically correct but the user experience fails.

The Low-Contrast Desert

We see axe-core miss low-contrast text constantly. Low contrast text is the number one WCAG failure by volume ^[3], and it's almost impossible for an automated tool to catch at scale.

Why? Because contrast depends on context. A color pair that fails WCAG AA on a button might pass on a disabled state. A background image might lower contrast for some users but not others. Anti-aliasing, subpixel rendering, font weight—all of these move the needle. When we audit, we take screenshots. We zoom to 200%. We check every interactive state. We measure with tools. We ask: would a user with low vision be able to read this reliably? Axe cannot answer that question. It can only report what the CSS says.

Missing Alt Text and the Context Problem

Axe-core flags empty alt attributes. That's mechanical. But we see it miss the harder case: alt text that exists but doesn't describe the image.

In our audits, we've found patterns like this: a financial services site where every image had alt text—axe-core returned green—but half the alt text was either a filename or a generic placeholder. "image.png." "photo-1." "decorative." These pass the technical rule. They fail the user. Someone using a screen reader gets no semantic value.

We know from WebAIM that automated tools can only identify some accessibility issues ^[6]. Alt text quality isn't one of them. We have to read it. We have to ask: does this convey what the image conveys? Does it add information or just check a box?

Form Labels and Hidden Intent

We see axe-core flag missing <label> elements reliably. Good. But we also see forms that have labels—technically correct—and still fail users because the label is visually hidden or programmatically mismatched.

One pattern we encounter often: a label exists in the markup but is positioned off-screen via CSS, or it's associated with the wrong input. Axe catches some of these. Not all. The DOM is correct on paper, but the user experience is broken. We have to manually verify that the label appears where the user expects, that it's visually associated with its field, and that the programmatic relationship holds under zoom and reflow.

Form accessibility requires intent. A developer has to decide: is this field required? Is this error critical or informational? Should this field be grouped with others? Axe doesn't make those calls. We do.

Keyboard Navigation and Sequential Logic

Axe-core can flag missing focus indicators and tab order issues in the DOM. But we consistently find that sites pass automated scans and still fail keyboard navigation in practice.

In our testing, we've encountered component libraries where every button had a focus state, every input was in the DOM, and axe-core was happy. But the tab order moved backwards through interactive panels, skipped elements entirely, and trapped focus in modals. These are behavioral problems. They live in JavaScript, in state management, in the order elements are rendered. A static analysis tool cannot see intent or flow. It sees attributes.

When we audit, we put the mouse away. We tab through the entire page. We test with a screen reader. We try keyboard-only workflows. Axe gives us a foundation. The rest is operational testing.

What You Have to Do

If axe-core catches 57% of issues, you own 43%. That ownership isn't optional. It's WCAG.

Our recommendation is structural. First: run axe-core. Automate the easy wins. Fix every finding. Second: run a manual audit focused on the gaps we've outlined—contrast, alt text quality, form usability, keyboard navigation. Third: test with actual assistive technology. NVDA on Windows, JAWS if you have access, Voice Control on macOS, TalkBack on Android. Test with users who rely on these tools.

There's no shortcut. Accessibility requires both machines and humans. The machines are fast and cheap. The humans are slow and expensive. But the humans catch the things that matter most—the things that actually affect whether a user can accomplish a task.

If you're auditing at scale or building accessibility into a development workflow, we built Parallax to make the 43% visible and actionable. It combines automated scanning with manual testing checklists and team workflows. Most teams we work with use axe-core as the foundation inside Parallax, not as a standalone tool ^[7]. The scan is the start. The audit is the substance.

Check out Parallax to see how audit workflows can catch both the automated wins and the human-dependent issues that axe-core leaves behind.

Morton Technology Consulting LLC — WCAG 2.1 AA audits for Florida government agencies. Parallax audit → · WCAG Readiness Kit → · All posts →