From a blind person’s perspective: a screen reader is not a debugger console

The strangest digital accessibility problems I increasingly see in modern applications are not missing labels, broken headings, or even keyboard traps.

The problem is communication itself. More precisely, the way developers think about screen reader messages. I feel like I have finally understood where this problem partly comes from.

Speech viewer windows – a helpful tool?

Many screen readers include speech viewer windows. They are very useful tools. They allow sighted people, developers, testers, technical support teams, or product helpline staff, to understand what the screen reader is announcing. They also help when remotely supporting blind users or reproducing difficult bugs.

For those unfamiliar with them: speech viewer windows are small panels that usually float at the bottom of the screen above other windows. Whenever the screen reader announces something, that information is displayed in a similar way to subtitles in a film, but in a dedicated place. As with subtitles, settings such as font color and size can be changed. In some screen readers, you can scroll back through several previous messages. In others, only the message currently being announced is visible, and often not even in full. Just like subtitles in a film, it moves along with the spoken text.

The problem is that visually, these windows look almost exactly like something else: console logs. And I have the impression that this similarity quietly influences the way we think about accessibility. Because when screen reader messages start to look like text in a console with errors or statuses, accessibility starts to be treated like a system for emitting events.

• The state changed? Announce it.
• Validation failed? Announce it.
• A section updated? Of course, announce it.
• Three errors appeared? Fire three alerts.
• Five errors appeared? Well, five role="alert" elements can be done too.
• Loading finished? Announce success.
• Something refreshed again? Announce it again, why not.

Technically, in most cases the information will indeed appear. Well, maybe apart from those five role="alert" elements, which probably will not fire.

But human communication is not a telemetry stream. A console can generate hundreds of lines per second. And maybe your AI agent will manage to make sense of it, although it will probably be too much information at once even for that. A human certainly will not.

Speech is sequential. Time-based. Interruptible. Fragile. When it is interrupted, part of the context can simply disappear. A blind user does not “parse events”. They listen. And listening has a cognitive cost.

Forms reveal this best

Unfortunately, this is most noticeable when working with forms. Imagine this scenario: the user submits a form. And suddenly:

• focus moves,
• the page scrolls,
• an error summary appears,
• several role="alert" elements fire at the same time,
• error messages appear,
• aria-describedby changes,
• buttons refresh,
• sections expand.

Visually, everything may look perfectly accessible. But the real screen reader experience starts to feel like chaos:

• interrupted messages,
• disappearing alerts,
• duplicates,
• cut-off sentences,
• unstable focus,
• or a complete loss of orientation.

Sometimes only the first error is read. Sometimes only the last one. Sometimes nothing is read at all. Sometimes the screen reader starts saying one thing while the focus is already somewhere else. And honestly, it is often best to go through the form again from the beginning, because otherwise I am almost certain I will miss something.

And the developer looks at the speech viewer and thinks: “But everything fired correctly.”

The point is that accessibility is not about whether all events or alerts fired. The question is rather: did the person understand what just happened? That is a huge difference.

Developers are not the bad guys

Interestingly, most of these systems are created with good intentions. Developers want to inform the user that something has changed. So they add another message. And another. Until the interface starts to resemble a storm of notifications rather than communication.

And the result? Well, quite often it is the exact opposite of what was intended. Not because of bad will, but because of the console. Literally.

As an advanced user and a blind person, I rarely need a huge number of messages. Even beginner screen reader users can become overwhelmed by them. It is worth providing messages that are stable. Predictable. Messages that allow the user to recover context. Well-designed messages and interfaces are those in which product teams understand that the amount of audio information the human brain can process is limited.

When our trainees, who are sighted, learn how to use a screen reader, they often mention headaches or extreme fatigue after only a short time of listening to things announced by synthetic speech. It is also true that using a screen reader every day requires practice, time, and developed habits. But if cognitive fatigue appears in trainees after just a few or a dozen minutes, why do product teams assume that blind users do not experience it?

The alternative

Sometimes the best accessibility decision is not: “Let’s announce everything.” Much more often, a better choice is:

• fewer messages,
• better structure,
• clearer navigation,
• stable focus,
• and persistent information that users can consciously return to.

A screen reader is not a debugger, a tool for checking whether code works correctly. And a blind user is not following logs in a terminal.

Accessibility is communication. And communication falls apart surprisingly quickly when we forget that there is a real human nervous system on the other side.

So what about speech viewer windows?

Speech viewer windows are very useful tools. They support communication and make it easier to solve problems between a screen reader user and a sighted person. But when we start treating them like console preview windows, the results are disastrous.