20 Years with a Screen Reader: What Developers Still Get Wrong

I am blind, and I have used the JAWS screen reader every day for about twenty years. I fix phones and computers, and I build accessible software: the Ultra suite, a set of creative tools like a video editor and an audio editor that blind and sighted people can both use.

Blind people talk about accessibility problems all the time. We talk about them on mailing lists, in forums, in private groups. The people who could actually fix them almost never read those places. So this time I am writing in public, for every developer, designer and product team who will ever build a button.

None of what follows is rare. I hit these problems almost every week.

1. Buttons and fields with no name

This is the most common problem, and the easiest to fix. A sighted person sees a magnifying glass and knows it means search. My screen reader sees an image with no text and says "button". Or "button, button, button", ten times in a row. Which one sends the form? Which one deletes my account? I have to guess.

Text fields are the same. I land in an edit box and JAWS says "edit". Is it my name, my email, my phone number? If the label is just grey text placed near the field, a screen reader does not know they belong together.

The fix takes seconds:

<!-- Bad: a screen reader says only "button" -->
<button><svg>...</svg></button>

<!-- Good: a screen reader says "Search, button" -->
<button aria-label="Search"><svg aria-hidden="true">...</svg></button>

<!-- Bad: placeholder is not a label -->
<input type="email" placeholder="Email">

<!-- Good: the label is tied to the field -->
<label for="email">Email</label>
<input type="email" id="email" autocomplete="email">

The same rule applies in mobile apps: contentDescription on Android, accessibilityLabel on iOS. Every control a person can touch needs a name a person can understand. Not "btn_submit_2". Not nothing.

2. The CAPTCHA wall

A CAPTCHA asks me to prove I am human by doing the one thing I cannot do: look at a picture. Pick all the traffic lights. Type the blurry letters. The audio version, when it exists, is often so distorted that it fails too.

So the test meant to stop robots stops me. And when it sits in front of registration, login or payment, it locks me out of the whole service.

There are better options. Rate limiting, email or SMS verification, invisible risk checks, and passkeys all stop bots without asking anyone to see. If you must use a challenge, test it with a screen reader before you ship it, and give people another way through.

3. Sites I simply cannot use

Recently I wanted to subscribe to a water dispenser from Knjaz Natura, a water delivery service here in Serbia. A simple task: open the site, register, choose a plan. I could not do it. Unlabeled fields, controls my screen reader could not reach, a page that did not behave like a page. In the end I had to call someone who can see to finish the registration for me.

Think about what that means. I am a developer. I have used screen readers for twenty years. And I still needed help to sign up for water. Every person who gets stuck like this is a customer you lose, and most of them will never write to tell you why.

Before you launch, try this: turn off your monitor, start NVDA (it is free) or VoiceOver, and complete your own main task using only the keyboard. If you cannot finish it, neither can we.

4. Redesigns that take it all away

KupujemProdajem is the biggest classifieds site in Serbia. For years it was fantastic with a screen reader. I could search, read listings and message sellers with no problems at all.

Then came the redesign. Since then, neither the website nor the app works for me. Content my screen reader cannot read, pages I cannot navigate, the same problems everywhere.

This hurts more than a site that was never accessible, because it shows the work had already been done, and then it was thrown away. A new design is a chance to improve accessibility, not a reason to lose it. Put screen reader testing in your redesign checklist, next to performance and browser testing. And keep the users who relied on the old version in the loop.

5. It can be done: Microsoft

I do not want this to be only complaints, because some companies get it right. Microsoft is the best example I know. Office is fully accessible to me: I write, edit and work in it every day with JAWS. Windows is solid too.

That did not happen by accident. It happens when accessibility is part of how a company builds, not a fix added after launch. If a company as big as Microsoft can do it across products used by hundreds of millions of people, a registration form can do it too.

What I ask of every developer

Whatever you build, a website, an app, a small internal tool, check it with someone who uses a screen reader. If you cannot find that person, at least ask an AI assistant to review your interface for accessibility. Either one will catch most of what I described here.

The checklist is short:

1. Every button has a clear name a screen reader can say.
2. Every field has a real label tied to it, not just a placeholder.
3. Everything works with the keyboard alone.
4. No CAPTCHA that depends only on sight.
5. Every redesign is tested with a screen reader before release.

None of this is hard. It costs minutes when you build it, and hours, or customers, when you do not. And if you want to know what it is really like, ask us. We have been waiting a long time for someone to ask.

I am Demir Ajvazi, a blind developer from Serbia building the accessible Ultra suite. You can find my work on GitHub.