In the Weeds: How to Rehearse a Screen Reader Read-Through Without Installing JAWS

It's 9:12 on a Tuesday morning, and I have been listening to my own homepage for an hour. Not reading it. Listening. A voice that sounds like a mid-1990s GPS is telling me, "link, link, link, button, heading level two, link, main, navigation, link, link." Somewhere in there is the value proposition of a product I have been building for eight months. I cannot find it. And I wrote the thing.

This is the part of the week where I understood, in a way that bar charts and audits had never managed, why screen reader users give up on most of the web.

The honest framing of this piece is: I am a sighted designer. I do not use a screen reader to live. Everything I am about to say is about rehearsing a read-through — a dress rehearsal before the real show, where the real show is actual testing with actual assistive-tech users. If you skip the real show, the dress rehearsal is a lie. If you do the real show and skip the dress rehearsal, you waste the testers' time on the things a machine would have caught. Both pieces matter. This article is about the cheap one.

Why the dress rehearsal is worth doing at all

Here is the argument against rehearsing. Real screen reader users move through a page differently than you will on your first try. They have muscle memory for rotor gestures and heading jumps and landmark navigation that took years to build. A sighted person fumbling through VoiceOver for thirty minutes is not simulating anything real; they are simulating a sighted person fumbling through VoiceOver.

That's a real objection, and it is the reason most designers either do a bad rehearsal or skip rehearsing and promise themselves they'll "do real testing later." Later never comes, or it comes once, after a complaint, and then never again.

Here is the argument for rehearsing. Half the bugs a screen reader user will find on your site are not subtle. They are not things that require expertise. They are things like "the logo link says the word 'logo' twice," and "the main heading of the page is a <div> styled to look big," and "the primary button has no accessible name at all, so the screen reader just says 'button, button.'" You do not need to be an expert to find these. You need to spend ten minutes listening.

The expert-level bugs — the ones where the semantics are technically correct but the experience is terrible — those require a real user. The basic bugs do not. And the basic bugs are most of them.

The dress rehearsal has one job: catch the basic bugs before they cost a real tester's time.

The setup (you don't need JAWS)

JAWS is the industry-standard Windows screen reader. It is excellent, it is expensive, and setting it up well is a day-long project. You do not need it for a rehearsal. Here is the shorter path.

If you are on a Mac, you already have a screen reader: VoiceOver. Cmd + F5 turns it on. Turn the speech rate down first in System Settings → Accessibility → VoiceOver → Speech, because the default rate is calibrated for daily users and will make your first hour feel like being yelled at in a second language.

If you are on Windows, NVDA is free, open-source, and what most real users on Windows actually use. It installs in about a minute.

If you are on Linux, Orca. Same deal.

You will also want 🔊prompt-screen-reader-walkthrough in another window. We'll come back to this in a moment. The TL;DR is that you do not want to do the rehearsal alone. You want the AI to do a parallel pass with you, because the AI will notice things you miss and you will notice things the AI misses, and the overlap of your two lists is shorter than either list alone.

The first pass: let the AI narrate the page first

Before you put on headphones and start fumbling with VoiceOver, run 🎙️skill-the-screen-reader-rehearsal on the page you want to test. Paste the URL. Ask it to narrate the page top to bottom the way a screen reader would, flagging anything that would be confusing, missing, or duplicated.

This is the part where people ask me, "Isn't that just reading the DOM?" and the answer is: mostly yes, but with opinions. A screen reader does read the DOM. The thing it does that is not "just reading" is handle implicit semantics (every <button> is announced as a button, every <h1> as a heading, every <main> as a main landmark), ignore CSS-only structure, and surface the accessible name of each interactive element using the accessible name computation algorithm, which is a spec nobody reads and everybody should.

The AI's narration is an approximation. It is good at the first 80% — the heading order, the landmarks, the obvious accessible names, the missing alt text, the suspicious ARIA — and bad at the last 20%, which includes things like live region timing, focus order weirdness, and how a specific screen reader on a specific browser will actually handle a specific edge case. For the rehearsal, 80% is fine.

What you're looking for in the narration:

Does the page make sense in reading order? A sighted reader can scan a page non-linearly — headline, pull quote, headshot, body. A screen reader reads it top to bottom, top of DOM to bottom. If the most important thing on the page is the last thing announced, you have a problem, and the problem is not screen-reader-specific; it is a reading-order problem that sighted users also have, they just aren't forced to notice it.

Are the heading levels in order? Jumping from h1 to h4 back to h2 is a classic bug. It usually comes from styling a <div> to look like a heading and then using <h4> somewhere else because it "looked right." Screen reader users navigate by heading. Broken heading order is like a broken table of contents.

Do the interactive elements have names? Every button, link, input. Every one of them needs an accessible name, and the name has to say what the thing does, not what the thing is. "Button" is not a name. "Submit the form" is a name. "Close modal" is a name. "Learn more" is barely a name and gets worse the more times it appears on the same page.

Is anything announced twice? This happens a lot with icon buttons that have both aria-label and visible text, and with <img> elements inside <a> tags where both have the same description. The result is "home, home, link" and it is a clear sign nobody has listened to the page.

Is anything not announced at all? This is worse than the twice problem. An icon-only button with no aria-label is a silent hole in the page.

Write down what the AI finds. Don't fix anything yet.

The second pass: your ears

Now turn on VoiceOver (or NVDA, or Orca) and actually listen to the page.

You will be bad at this. That is correct. Being bad at it is the point. You are not trying to use a screen reader efficiently. You are trying to hear what the page sounds like.

Here is a rule that will save you thirty minutes of frustration: do not try to navigate with the mouse. Unplug it if you have to. Use the keyboard exclusively. Tab, Shift+Tab, and the arrow keys. The rotor, if you're feeling brave (VoiceOver: Ctrl + Option + U; NVDA uses element lists via Insert + F7). If you keep reaching for the mouse, you are not rehearsing. You are cheating.

Listen for:

The first thirty seconds. What does a first-time user hear when they land on the page? If the first thing announced is "skip to content, link," good. If the first thing announced is twelve nav links followed by "menu, button, expanded, false," you have buried the lede. The cost of a "skip to content" link is five minutes of work and it is the single most requested affordance from screen reader users. If you don't have one, that is your first ticket.

Form fields. This is where most forms fall apart. A field without a label is announced as "edit text" or "edit, blank." A field with a label read from the placeholder alone disappears the moment you start typing. A field with an error message that only appears visually next to the field is a silent landmine. Run through your forms tab by tab and listen. If you hear "edit text, edit text, edit text," you have a form label problem, and 📝prompt-form-label-audit will catch the rest in about two minutes.

Modals and dialogs. When a modal opens, focus should move into it. When it closes, focus should return to the element that opened it. The modal should announce its own name and role. Pressing Escape should close it. If any of these are missing, the modal is a trap, and modal traps are the single most common reason screen reader users rage-quit a site. Listen for what happens when you open, navigate, and close each modal.

Dynamic content. Toasts, notifications, "your changes have been saved" messages. These need live regions (aria-live) or they will never be announced at all. The sighted user sees the toast. The screen reader user gets nothing. Trigger each one and listen.

The point of the ear pass is not to be comprehensive. It is to build an intuition for what "wrong" sounds like. Once you have that intuition, you will hear it coming through your design reviews for the rest of your career. That is the real payoff.

The third pass: the auditor comparison

Now, back to the AI. Open 🔍The Accessibility Auditor — this is the soul I keep in a pinned tab for exactly this kind of work. Paste in the list of things your ears caught. Ask the auditor to add anything you might have missed.

This is the part where the rehearsal earns its keep. You will have caught some things the AI missed on its first pass, usually in the "this is technically fine but feels wrong" category. The AI will have caught some things you missed, usually in the "this is semantically broken in a way you didn't notice because you weren't reading the DOM" category. The union of the two lists is your rehearsal output.

Do not ship the union as a ticket list. Prioritize it. Three buckets:

1. Broken — the thing is unusable. Missing button names, unescapable modals, form fields with no labels. These are P0. Ship fixes this week.
2. Confusing — the thing works but is hostile. Heading order jumps, redundant announcements, unclear link text. These are P1. Ship fixes this sprint.
3. Imperfect — the thing could be better. Nice-to-have landmark improvements, tighter skip links, cleaner ARIA. These are P2. Add to the backlog. Revisit with the real users.

The separation matters because the rehearsal will produce a list long enough to be discouraging. Most items on that list are not actually blocking anything. Three or four of them are, and those are the ones that matter.

Where the rehearsal stops

I want to be honest about the limits of what you just did, because the temptation after a rehearsal is to think you are done, and you are not.

Real screen reader users will find things your rehearsal missed. They will find:

• Efficiency problems. Your page technically works, but moving through it takes four times as long as it should, because the structure is fighting the rotor.
• Context problems. A link that says "read more" is confusing to you on your second listen, but it is a thousand times worse in the middle of a list of thirty of them, read out of context, after an hour on the site.
• Real-world problems. Users who have been using screen readers for twenty years have habits. Those habits interact with your design in ways neither you nor an AI will predict. The only way to find those is to watch a real user use the site.

The rehearsal does not replace real testing. It makes real testing cheap enough that the things the tester finds are worth finding. If the tester spends their first ten minutes on "your main button has no label," you have wasted their time. If the tester spends their first ten minutes on "your whole flow assumes I can skim, which I can't, and that's the actual problem," now we're somewhere.

Recruit real users. Pay them. Listen to them. The dress rehearsal is to the show what batting practice is to a baseball game. Necessary, not sufficient.

Do this tonight

• Pick one page. Not your homepage. Your highest-traffic signup or checkout page.
• Run 🔊prompt-screen-reader-walkthrough on it and read the output.
• Turn on VoiceOver or NVDA. Unplug your mouse. Tab through the page from top to bottom. Write down the three things that felt most wrong.
• Take those three things to 🔍The Accessibility Auditor and ask for fix suggestions in the framework you actually use.
• File three tickets. Not thirty. Three. Ship them this week.

Next week, do it again on a different page.

After a month, you will have listened to more of your own product than most designers listen to in a career. The sticky note about "real a11y testing next quarter" will still be on your monitor. But the product underneath it will be different, because you finally heard it.

Part of the a-gnt "In the Weeds" series. Written by a-gnt Community.