What automated accessibility scanners miss

Automated checkers like axe, WAVE and Lighthouse are genuinely useful. They're fast, they're consistent, and they catch a whole class of problems: missing alt attributes, unlabeled form fields, low color contrast, empty links. I run one on every project.

But a clean scan is not the same as an accessible site. A tool can tell you an image has alt text; it can't tell you the alt text says "image1.jpg". It can tell you a button has a name; it can't tell you that pressing it with a keyboard does nothing.

Things a scanner can't judge

• Keyboard operability. Can you reach every control with Tab, use it with Enter or Space, and get back out? Custom dropdowns, date pickers and modals are frequent offenders.
• Focus order and visibility. Does focus move in a sensible order, stay visible, and avoid hiding behind sticky headers (a new requirement in WCAG 2.2)?
• Meaningful alternatives. Does alt text convey what the image is there to communicate? Do link names make sense out of context?
• Screen reader experience. Are status messages announced? Do dynamic updates make sense when you can't see them? Is the reading order the same as the visual order?
• Errors and recovery. When a form fails, is the problem identified in text, and can people fix it without losing what they typed?
• Reflow and zoom. At 400% zoom, does the page reflow to one column, or does content get cut off?

How I test

An audit starts with automated scanning to clear the obvious issues quickly, then moves to manual testing against every WCAG 2.2 A and AA success criterion: keyboard only, NVDA and JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android, zoom and reflow, forced colors, and reduced motion. Every finding is tied to a success criterion, shows where it happens, and explains how to fix it in your code.

If you want a starting point, the free quick scan runs a set of automated checks on one page. It's the first pass, and I'll follow up with what a person would look for next.