Testing Accessibility With Real Assistive Tech, Not Just Scanners

The first time I used a screen reader on a site I had built, I was embarrassed within about thirty seconds. The site passed every automated check I had thrown at it. The contrast ratios were fine, every image had alt text, every form field had a label. And yet when I closed my eyes and tried to buy something using only VoiceOver and the keyboard, I got stuck on the second step. The scanner had told me the page was healthy. The screen reader told me the truth.

This is worth dwelling on, because the gap between those two verdicts is where most accessibility work goes wrong. A scanner checks whether the markup follows rules. A screen reader checks whether a person can complete a task. Those sound like the same thing, but they aren’t, in the same way that a spell checker and an editor aren’t the same thing. Your document can be free of spelling errors and still be incomprehensible.

Take alt text. A scanner can verify that an image has an alt attribute. It cannot verify that the alt text is useful. I have seen product photos whose alt text was the filename, literally “IMG_4club2.jpg.” The scanner is satisfied. The blind shopper hears a string of gibberish where the product should be. Technically compliant, practically useless. The only way to catch this is to listen to the page the way a screen reader user would, and notice that what you hear doesn’t tell you what you’d need to know.

Or take focus order. When you tab through a page, the keyboard focus should move in an order that makes sense: through the navigation, into the main content, through the form fields top to bottom. Nothing in the HTML spec forces this. A page can be built out of absolutely positioned pieces whose visual order has nothing to do with their order in the document, and the tab key will hop around the screen like a flea. Scanners mostly can’t see this, because “makes sense” is not a property of markup. It’s a property of experience. You find it by pressing Tab and watching where the focus goes, which takes two minutes and requires no special tools at all.

So here is the practical advice, and it’s cheaper than you’d expect. You don’t need to buy anything. If you’re on a Mac, VoiceOver is built in; press Command-F5 and it starts talking. On Windows, NVDA is free. On your phone, both iOS and Android ship screen readers. Pick the one task on your site that makes you money, whether that’s checkout, signup, or a contact form, and complete it with the screen reader on and the mouse untouched. The first time will be slow and frustrating, and that frustration is data. Everything that confuses you is confusing your users, except they don’t have the option of turning the screen reader off.

You will find a particular class of bug this way that nothing else finds: things that are announced wrong. A button that a sighted user reads as “Add to cart” but that the screen reader announces as just “button,” because the label is an icon with no accessible name. A custom dropdown that looks like a dropdown but is actually a pile of divs, so the screen reader has no idea it’s interactive at all. An error message that appears visually when the form fails but is never announced, so the blind user submits, hears nothing, and assumes the site is broken. Each of these is invisible to a scanner because the markup isn’t wrong in any rule-checkable way. It’s just silent where it should speak.

None of this means scanners are useless. I build automated auditing tools for a living; GazeSite runs automated checks on every site it scans, and I think they’re worth running on every deploy, because they catch the mechanical mistakes cheaply and repeatably. Missing labels, broken contrast, images without alt attributes: let the machine find those, every time, forever. The mistake is treating the scanner’s approval as the finish line rather than the starting line. Automation clears the ground so that when you do the human test, you’re finding the interesting problems instead of the boring ones.

The business case is simpler than people make it. Somewhere between one in twenty and one in ten of your visitors is using some form of assistive technology or adaptation: a screen reader, magnification, keyboard-only navigation, voice control. When your checkout silently fails for them, you don’t get a bug report. You get nothing. They leave, and the analytics record it as just another abandoned cart, indistinguishable from someone who got distracted by a phone call. The revenue you’re losing to accessibility bugs is perfectly camouflaged as ordinary churn. The screen reader test is how you take the camouflage off.

There is also something that happens to you as a builder when you do this regularly, which is that you stop thinking of accessibility as a checklist and start thinking of it as a second rendering of your site. Every page you make has a visual rendering and an audible one, and you are responsible for both. Once you’ve heard your own site, you can’t unhear it. You’ll catch yourself, mid-implementation, thinking about what the screen reader will say. That instinct is worth more than any audit, because it prevents the bugs instead of finding them.

So run the scanners. Then close your eyes.