Why Automated Tools Only Catch 30% of Accessibility Barriers

Every time I start an accessibility audit, I run axe-core. I run Lighthouse. I pull the automated report and scan the violations list. And then I put on my headphones, open JAWS, and actually navigate the site — because that's where the real problems live.

The 30% figure comes from a WebAIM study, and it holds up in my experience: automated tools reliably catch roughly a third of WCAG failures. The other two-thirds require a human — specifically, a human using assistive technology in the way your users actually do.

This isn't a knock on automated tools. axe-core is excellent at what it does. But what it does is check for structural, machine-verifiable violations. The accessibility problems that hurt real users most are frequently none of those things.

What Automated Tools Are Good At

To understand the gap, start with what automated tools actually check well:

• Missing alt attributes — if an <img> has no alt, axe catches it.
• Color contrast ratios — computable from CSS values, Lighthouse flags these reliably.
• Missing form labels — an unassociated <input> is detectable in the DOM.
• Invalid ARIA roles — using role="banana" shows up immediately.
• Missing page title or language attribute — structural, machine-checkable.
• Duplicate IDs — straightforward DOM inspection.

These matter. Fix every one of these. But clearing your axe-core report does not mean your site works for screen reader users. Not even close.

The Unlabeled Button Problem Automated Tools Miss

Here's a violation I encounter on nearly every e-commerce audit. A button has no accessible name — no aria-label, no visible text, no title. axe-core flags it. So far so good.

But then there's the subtler version: a button that has text, technically, but that text is only meaningful with visual context. A "Remove" button that sits next to a product image and name on screen — visually, it's clear what you're removing. In JAWS, I hear "Remove, button." Remove what? The page has twelve of them. Every one announces the same thing.

<!-- Automated tools: PASS. Screen reader users: FAIL. -->
<button type="button" class="remove-btn">Remove</button>
<button type="button" class="remove-btn">Remove</button>
<button type="button" class="remove-btn">Remove</button>

<!-- The fix: visually hidden context -->
<button type="button" class="remove-btn">
  Remove
  <span class="sr-only">Wireless Headphones, Black</span>
</button>

axe-core sees a button with text content. It passes. JAWS users are left guessing which item they're about to remove from their cart.

Reading Order and DOM Order

Screen readers navigate the DOM in source order. When developers position elements visually using CSS — floats, absolute positioning, grid placement — the visual order and the DOM order diverge. Sighted users follow their eyes. I follow the DOM.

I regularly audit sites where a sidebar is rendered before the main content in the HTML, then visually placed to the right using CSS. Every screen reader user has to wade through the entire sidebar — navigation, ads, related links — before reaching the main article. It looks fine. Automated tools see nothing wrong. It's genuinely painful to navigate.

The only way to catch this is to actually tab through the page and listen. There is no automated check for "the reading order makes sense."

Focus Management in Single-Page Applications

This is where modern web development creates the most invisible barriers. When a React or Vue app renders a new view without a full page load, screen readers don't know anything changed. In a browser, a page load resets focus to the top of the document and announces the new page title. In a client-side navigation, none of that happens unless you explicitly manage it.

<!-- After a route change, you need to: -->

// 1. Update the document title
document.title = 'Order Confirmation — Shop';

// 2. Move focus to a meaningful location
const heading = document.querySelector('h1');
heading.setAttribute('tabindex', '-1');
heading.focus();

// 3. Announce the navigation (alternative approach)
// Use an aria-live region
liveRegion.textContent = 'Navigated to Order Confirmation page';

Without this, I'm stuck. I activate a link, something happens on screen that I can't see, and JAWS is completely silent. The page changed — I just have no idea what it changed to or where I am in it. Lighthouse gives you a perfect accessibility score.

Dynamic Content and Live Regions

When content updates on a page — a filter is applied, a notification appears, an error message shows — screen readers need to be explicitly notified. That's what ARIA live regions are for. Without them, updates happen silently.

I've tested checkout flows where clicking "Apply Coupon" updates a total and shows a success message — visually. In JAWS, I hear nothing. The coupon applied, or it didn't. I have to navigate back through the form to find out.

<!-- Status messages need a live region -->
<div
  role="status"
  aria-live="polite"
  aria-atomic="true"
  class="sr-only"
  id="coupon-status"
></div>

<!-- Then inject your message via JS -->
document.getElementById('coupon-status').textContent =
  'Coupon applied. New total: $47.50';

An automated tool can't tell you whether your live regions are firing at the right time with the right content. That requires testing with an actual screen reader.

Custom Interactive Widgets

Date pickers. Autocomplete dropdowns. Sliders. Accordion menus. Multi-select listboxes. Every one of these is a custom widget, and every one needs a complete keyboard interaction pattern — not just focusable, but navigable with arrow keys, operable with Enter and Space, escapable with Escape, and announced correctly at every state.

I cannot count the number of date pickers I've encountered that are technically focusable but completely inoperable. Tab lands on the "calendar" widget. What do I press next? Arrow keys? Enter? Nothing responds. I'm stuck. axe-core: zero violations.

The Practical Takeaway

Run automated tools on every build. They're fast, they're cheap, they catch real problems, and they're an excellent first gate. But treat a clean automated report as the starting line, not the finish line.

The barriers that actually prevent your users from completing tasks — buying something, filing a form, accessing their account — are overwhelmingly the kind that only surface when a real person with a real screen reader tries to use your product.

In 25+ years of using JAWS daily, I've learned to identify these patterns quickly. But there is no substitute for the test itself.