What automated accessibility scans miss (and how to catch it)

Tools like Lighthouse, axe, and WAVE have made accessibility testing a lot easier. You run a scan, get a score, and fix the red stuff. That's real progress. The problem is what usually happens next. The score turns green, the ticket gets closed, and everyone assumes the site is accessible.

I've seen plenty of sites with near-perfect automated scores that you can't get through with just a keyboard, or forms where a screen reader user can fill out the whole thing without ever hearing what went wrong. The scanner wasn't wrong. It just wasn't checking for those things.

Why scanners fall short

Automated tools are really good at checking things you can figure out just by looking at the code. Does this image have an alt attribute? Does this text have enough contrast? Does this input have a label? Where they struggle is anything that takes judgment or actually using the page.

A scanner can tell you an image has alt text. It can't tell you the alt text says "image123.jpg". It can tell you a button exists. It can't press Tab twenty times and notice that focus disappeared behind your sticky header.

Automated testing tells you whether the code follows certain rules. Manual testing tells you whether a person can complete the task.

The Web Content Accessibility Guidelines (WCAG) 2.2 are written around what people need, not around rules for code. That's why a lot of the guidelines just can't be fully checked by a machine.

Seven things scanners routinely miss

1. Keyboard traps and illogical focus order

A lot of people get around the web using only a keyboard, or devices that work like one. Custom dropdowns, carousels, date pickers, and modals are where things usually go wrong. A scanner won't notice when focus gets stuck inside a widget (2.1.2 No Keyboard Trap) or jumps from the header to the footer and back again (2.4.3 Focus Order).

2. Focus that's invisible or hidden

Removing the browser's focus outline with outline: none is still really common. And even when there is a focus style, WCAG 2.2 added 2.4.11 Focus Not Obscured (Minimum), which means the focused element can't be completely hidden by things like sticky headers, cookie banners, or chat widgets. Scanners almost never catch this one because it depends on where you've scrolled and how the page is laid out.

Here's a simple setup that covers the basics:

:focus-visible {
  outline: 3px solid #4f43c9;
  outline-offset: 3px;
}

/* Keep focused elements clear of a sticky header */
html {
  scroll-padding-top: 5rem;
}

3. Meaningless accessible names

A scanner checks that a link or button has a name. It can't tell you that your page has twelve links that all say "Read more," or an icon button that just gets announced as "button." Screen reader users often jump through a list of all the links or buttons on a page, so each one needs to make sense on its own.

<!-- Ambiguous -->
<a href="/pricing">Read more</a>

<!-- Clear, without changing the visual design -->
<a href="/pricing">
  Read more<span class="visually-hidden"> about pricing</span>
</a>

4. Form errors nobody hears

This one is a classic. Someone submits a form, a red border shows up around a field, and that's it. If you can see the screen and you're using a mouse, you might notice. If you're using a screen reader, you get nothing. Good error handling points out which field has the problem, explains it in text (3.3.1 Error Identification), suggests a fix when it can (3.3.3 Error Suggestion), and makes sure the error actually gets noticed by moving focus to it or announcing it.

WCAG 2.2 also added 3.3.7 Redundant Entry, which basically means don't make people type the same thing twice in the same process, like re-entering a shipping address on the billing step.

5. Small or crowded touch targets

Also new in WCAG 2.2, 2.5.8 Target Size (Minimum) says buttons and links should be at least 24 by 24 CSS pixels, or have enough space around them that you won't accidentally tap the wrong thing. Tiny close icons, cramped pagination, and tightly packed social icons are the usual suspects. Some tools can flag this now, but deciding what counts as an exception (like a link in the middle of a sentence) still takes a person.

6. Interactions that require precise movement

2.5.7 Dragging Movements says anything you can drag also needs another way to do it. Think sortable lists, sliders, or map pins. If dragging is the only option, people with tremors or people using voice control can get stuck. The fix is usually pretty simple, like adding "move up" and "move down" buttons or letting people type in a value.

7. Content that breaks when zoomed

1.4.10 Reflow says your content should still work at a width of 320 CSS pixels without having to scroll sideways. That's about what you get when you zoom a 1280-pixel-wide browser to 400%. Fixed-width containers, sticky elements that take up half the screen, and data tables are usually the problem. And scanners don't zoom.

A 30-minute manual check

You don't need any special tools to catch most of these. Pick the most important thing people do on your site, like signing up, checking out, or requesting a quote, and try this:

1. Unplug the mouse. Complete the journey using only Tab, Shift+Tab, Enter, Space, Escape, and the arrow keys. Can you always see where focus is? Can you reach and operate everything? Can you escape every menu and dialog?
2. Zoom to 400%. At a 1280-pixel-wide window, zoom the browser to 400%. Does anything get cut off, overlap, or require horizontal scrolling to read?
3. Submit forms wrong on purpose. Leave required fields empty and enter invalid data. Are errors described in text, tied to their fields, and easy to find?
4. Turn on a screen reader for five minutes. VoiceOver is built into macOS and iOS; NVDA is free on Windows. Navigate by headings and by links. Does the structure make sense? Do buttons and links say what they do?
5. Check your own content. Read the alt text on key images and the headings on key pages. Would they make sense to someone who can't see the layout?

Write down every spot where you got stuck or confused. I promise that list will be more useful than any score.

Building accessibility into how you ship

An audit is a great place to start, but it works best when it isn't a one-time thing. The teams I've seen keep their sites accessible usually do a few things consistently:

• Run automated checks in CI so regressions in the easy-to-detect issues never reach production.
• Add a short keyboard-and-zoom check to the definition of done for new UI.
• Build accessible patterns once in a shared component library, then reuse them everywhere.
• Re-test key journeys after major redesigns or new feature launches.

Automated scans and manual testing aren't competing with each other. Use the scanner to catch the easy stuff quickly, and use real people to find the problems that actually stop your users.

← Back to all articles