---
title: What I Wish Developers and QA Teams Understood About Screen Readers
description: Explore the gaps between visual and auditory web experiences for screen reader users, and discover how to improve accessibility testing and design.
---

[Blog | UsableNet](https://blog.usablenet.com)

# [What I Wish Developers and QA Teams Understood About Screen Readers](https://blog.usablenet.com/what-i-wish-developers-and-qa-teams-understood-about-screen-readers)

 Written by [Michael Taylor](https://blog.usablenet.com/author/michael-taylor) | Sep 21, 2026, 1:15:00 PM

> **Editor's note:** Michael Taylor describes the barriers that clear an automated scan and still stop him cold, which is the category of problem most likely to be sitting on your site right now. New to the series? Start with [what a screen reader is and how it works](https://blog.usablenet.com/what-is-a-screen-reader).

One thing that has frustrated many other screen reader users and me for a long time is the disconnect between a website's visual version and the auditory version I have to work with. Now that we are heading into the last stretch of 2026, the gap between what gets caught in a lab, by an automated scan or by someone who does not use a screen reader daily, and what I actually hit on the web is still wide.

In this post, I want to walk through where that gap shows up for me, why I think so much of it survives testing, and what I wish the people building and checking these sites understood about how I use them.

## Sight and Sound

The hardest thing for me to get across is how an interface can look clean and intuitive and still be an utter disaster to use with a screen reader. A couple of examples show what I mean better than I can explain it.

On the shopping sites I use, more and more controls sit on top of the product image itself. Icon buttons like "Share" or "Add To Favorites" get overlaid right on the photo. Visually, I am sure that looks great and modern. In the code, it can be perfect too, with a proper image description and correct button labels.

In practice, those buttons are notoriously hard for me to use. My screen reader usually treats the image as one element and will not let me interact with its parts, so I cannot isolate a button and activate it. They also get skipped when I filter my navigation by button because they aren't sitting on the flat plane of the main page.

For a second example, take the flight search results on an airline website. The details for a single flight are usually laid out in a block that runs horizontally across the screen. When I get to that block with a screen reader, it announces each piece of information as focus advances, instead of reading the whole flight at once. I wrote about [what that does to comparing flight results](https://blog.usablenet.com/airline-website-accessibility-comparing-flight-results-while-blind) earlier this summer.

The problem is that the order I hear those details in is often illogical, so I cannot tell which pieces belong together or what a given number means in context. Visually it all looks correct. If someone who does not use a screen reader every day tested that page, it might pass inspection, because every piece of text is technically spoken.

That nuance is the whole difference. Everything gets announced, but the order and logic aren't there, and the interface is unusable anyway. What would work for me is hearing the entire block of details for one flight as a single announcement, with slight pauses between the pieces for clarity.

## The Shortcomings of Automated Accessibility Scans

None of this gets fixed until somebody finds it, so I want to talk about how these problems get caught, starting with automated scans. Based on the sites I use, many teams lean on them heavily. They are a great tool in accessibility work, but they don't catch everything, and I have two examples where one comes up short.

Images need a text description because that's all I get. What I want out of one is short and clear, just the details that actually matter in the picture. On a shopping site I use constantly, every homepage and product image carries the comically inadequate description "This Is A Graphic."

That tells me nothing at all about what is on the screen. My guess is those images sail through a basic scan anyway, because a description is technically there, even if it's useless.

Here is a second example. Another e-commerce site I use often has product videos for some of the items. The player itself is accessible in the obvious ways: starting the video, working the controls, and exiting the player. One major problem, though.

While the video is playing, my screen reader announces the seek slider progress every single time it advances one second. That turns into endless continuous speech that talks over the audio and makes the media impossible to consume. The pause speech command buys me about a second before the announcements start again. It happens even when my focus is elsewhere on the page, not on the seek slider.

Something is clearly wrong there. But if the button labels and the interactions are all correct on paper, my guess is that the page passes a scan too.

## The Human Element in Screen Reader Testing

This is where people have to enter the equation. If anyone had tried those product videos with a screen reader on, they would have found out right away that the media is unusable because the speech cannot be stopped. If anyone had tried to get something out of those product images, they would have known immediately that "This Is A Graphic" does not help a soul.

What I wish is that the people doing that manual testing had some grounding in how screen reader users actually work. Not only how the software operates, though that matters, but the habits and patterns behind how someone like me moves through a page. Without that, it is hard to see how a design choice or a technical flaw breaks the experience for a real person.

My previous post on [how I approach an unfamiliar website with a screen reader](https://blog.usablenet.com/how-i-shop-an-unfamiliar-website-with-a-screen-reader) is my best attempt at showing what that looks like from the inside.

Basic keyboard navigation alone doesn't get me there either. Like I said earlier, what you see is not always what you will hear. The barriers that stop me cold only show up when the screen reader gets used the way we use it every day.

If I could ask for one thing, it would be for whoever is testing to set the visual interface aside for a while and work through the site with no visual aid at all. That is the closest thing to my day. In my experience, it doesn't take long for problem designs, features, and layouts to give themselves away once the page is nothing but sound.

Real-world user testers are the last piece. We rely on a screen reader every day, so we are the ones most likely to catch the complicated problems that slip past an automated scan or a lab-style testing session.

What I keep coming back to is that intersection between how you see a website and how I hear it. It is bigger than an automated scan and a round of basic manual checks can cover. What I would love is for someone to walk a whole journey end to end, with the needs and navigation habits of real screen reader users in mind, and get as close to my perspective as they can from the outside.

## Common questions about screen reader testing

### **Can a website pass an automated accessibility scan and still be unusable with a screen reader?**

Yes, and both of my examples here did. An image described as "This Is A Graphic" has a description, so the scan is satisfied. A video player with correct button labels looks fine on paper even when the speech never stops.

### **What do automated accessibility scans miss?**

In my experience, the things that depend on order, grouping, and timing. A scan can confirm that text is present and that labels exist. It cannot tell you that the flight details came at me in an order that made no sense, or that the seek slider was talking over the video.

### **Why are buttons placed on top of a product image a problem for screen reader users?**

My screen reader tends to treat the image as one element, so I cannot get inside it to press the buttons. They also get skipped when I filter my navigation by button. My guess is that's because they aren't sitting on the flat plane of the main page.

### **Is keyboard testing enough to find screen reader barriers?**

Not for what I run into. Keyboard testing tells you focus can reach something. It does not tell you what I heard when it got there, or in what order.

## What to check in your own accessibility testing

Pick a page where information is grouped visually, a product tile or a search result row, and listen to how it announces: as one item, or as six separate stops in an order that may not match the layout. Check any control that sits on top of an image, and check whether a media player keeps talking once playback starts. A scan won't catch any of these, so finding them takes someone running the flow end to end with a screen reader.

If you want to hear the difference before you go looking, our [screen reader demo webinar](https://info.usablenet.com/webinar-registration-page-august-2026) is available on demand. Joseph DiNero of Helen Keller Services for the Blind navigates a modern ecommerce site with a screen reader while Jason Taylor walks through what strong and weak implementations of headings, links, buttons, forms, and page structure actually sound like. 

Barriers like these are the ones screen reader users hit mid-task, and they are the same kind that turn up in accessibility complaints. Finding them is one problem, and having the developer time to fix and maintain them is another.

[UsableNet Assistive](https://usablenet.com/technology/assistive-technology-services) is a managed service where our developers remediate and maintain accessibility issues on your live site through a JavaScript layer, with legal indemnity included under the terms of the agreement.

[Schedule a consultation](https://info.usablenet.com/contact) to talk through what your own site sounds like to a screen reader user.

 **Further reading:** Jeff Adams explains [why a perfect accessibility scan score isn’t the goal for an e-commerce site](https://blog.usablenet.com/a-perfect-accessibility-scan-score-isnt-the-goal-for-an-e-commerce-site-ai-makes-that-easy-to-forget), especially as AI makes scan findings easier to clear. 

[View full post](https://blog.usablenet.com/what-i-wish-developers-and-qa-teams-understood-about-screen-readers)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Michael Taylor"
  },
  "dateModified" : "2026-09-24T20:28:14.161Z",
  "datePublished" : "2026-09-21T13:15:00Z",
  "headline" : "What I Wish Developers and QA Teams Understood About Screen Readers",
  "image" : {
    "@type" : "ImageObject",
    "height" : 169,
    "url" : "https://3280432.fs1.hubspotusercontent-na1.net/hubfs/3280432/Screen-Reader-for-blind-visually-impaired.png",
    "width" : 300
  },
  "mainEntityOfPage" : "https://blog.usablenet.com/what-i-wish-developers-and-qa-teams-understood-about-screen-readers",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60,
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
      "width" : 60
    },
    "name" : "UsableNet Blog"
  }
}
```