Stop Auditing for Screen Readers and Start Building for Real Users

Why do so many accessibility guides fail to make websites usable for screen reader users? Because they treat compliance as a checklist and ignore the lived experience of the people the guidelines are meant to serve. That’s the core problem, and it leads to a lot of wasted effort. My thesis is blunt: stop treating screen reader accessibility as a box-ticking exercise. Instead, build for the real-world habits and pain points of screen reader users, and you’ll see better results with less work.

Screen Reader Users Are Not a Monolith

You might think of a screen reader user as someone sitting at a desktop with JAWS. Wrong. The WebAIM Screen Reader User Survey (2024) found that 91.3% of respondents use a screen reader on a mobile device, including 93.6% of those with disabilities. If your accessibility guide only covers desktop testing, you’re missing the majority of actual usage. And mobile screen readers behave differently: VoiceOver on iOS and TalkBack on Android have unique gestures and focus order. You need to test on both platforms.

Also, 71.6% of users rely on more than one screen reader. That means your site must work across JAWS, NVDA, VoiceOver, and others. NVDA, the free open-source Windows screen reader, is used by people in more than 175 countries and has been translated into over 55 languages. It’s not a niche tool; it’s a global standard. So when you write an accessibility guide, include NVDA testing as a baseline.

Headings and Landmarks Are Your Best Friends

When screen reader users land on a long page, how do they find what they need? 71.6% navigate by headings first. And 88.8% find heading levels very or somewhat useful. If your headings are just styled text without proper H1-H6 markup, you’re forcing users to listen to the entire page. That’s a terrible experience. Use real heading tags, nest them logically, and don’t skip levels. This is the single highest-impact fix you can make, and it costs nothing.

Landmarks (like <main>, <nav>, <header>) are equally important. They let users jump between regions. If you’re not using them, you’re making people wade through your navigation on every single page load. That’s not just annoying; it’s exclusionary.

The Real Problems: CAPTCHAs, Forms, and Images

What do screen reader users actually complain about? CAPTCHA remains the most problematic item, and respondents with disabilities were twice as likely to rank it as problematic. If your site uses CAPTCHA, you’re actively blocking blind users. There are accessible alternatives, like audio CAPTCHAs or logic puzzles, but many sites still deploy the worst kind. Fix that first.

Next, forms. One third of the 6.9 form inputs on the average home page are not properly labeled (WebAIM Million). That means when a screen reader user tabs to a field, they hear “edit text” with no clue what to enter. Always associate labels with inputs using the for attribute or wrap the input in a label. And don’t rely on placeholder text; it disappears and isn’t reliably announced.

Images: 16.2% of all home page images have missing alternative text (WebAIM Million). That’s 10.8 images per page on average. Every meaningful image needs an alt attribute. Decorative images should have empty alt. But don’t just stuff keywords; describe the function or content. If an image is a link, its alt text should describe the destination, not the image itself. 45% of images missing alt text were linked images (WebAIM Million), so that’s a common failure.

Why Automated Tools Won’t Save You

You might argue that automated tools like axe or Lighthouse can catch these issues. They can catch some, but they miss the big picture. The WebAIM Million found that 95.9% of home pages have detectable WCAG 2 failures, averaging 56.1 errors per page. That’s after years of automated testing being available. Clearly, detection alone isn’t solving the problem. Automated tools can’t tell you if your heading structure makes sense, if your alt text is meaningful, or if your CAPTCHA is usable. They also can’t test keyboard focus order or screen reader announcements. You need manual testing with actual screen reader users.

And don’t be fooled by ARIA. WebAIM found that home pages with ARIA present averaged more errors (59.1) than pages without ARIA (42). ARIA is powerful but easily misused. The first rule of ARIA is don’t use ARIA if you can use native HTML. A <button> is better than a <div role="button"> every time.

What You Should Do Instead

My recommendation: adopt a screen-reader-first mindset. Start every project by testing with NVDA and VoiceOver. Build a simple test script: navigate by headings, fill out a form, interact with a modal, and try a CAPTCHA. Recruit at least one screen reader user for user testing. Yes, it takes effort, but it’s the only way to catch the issues that matter. And remember that 85.9% of screen reader users say better websites, not better assistive technology, would have the biggest impact on accessibility. That’s a direct call to action for developers and designers: the ball is in your court.

So here’s the single most important thing to remember: accessibility is not about passing a checklist; it’s about enabling people to use your site independently. Stop hiding behind automated reports and start listening to screen reader users. Your guide should reflect that.

Sources

• WebAIM Screen Reader User Survey - https://webaim.org/projects/screenreadersurvey10/
• WebAIM Million - https://webaim.org/projects/million/
• NV Access - https://www.nvaccess.org/about-nv-access/
• Apple Accessibility - https://www.apple.com/accessibility/vision/