How to Test Your Website with a Screen Reader — A Beginner's Guide

Here's something that still surprises me after 16 years in this field: most developers have never used a screen reader. Not once. They build interfaces that millions of people will interact with using assistive technology, and they've never heard what their own product sounds like.

I don't say that to shame anyone. I say it because it's the single biggest gap in web development today. You wouldn't ship a product without looking at it in a browser. But every day, teams ship products without ever listening to them.

As someone who uses JAWS and NVDA every single day — not for testing, but to actually use the web — I want to give you a practical starting point. This isn't an academic overview. This is what I'd tell you if you sat down next to me and said, "Show me how to do this."

Which Screen Reader Should You Start With?

If you're on Windows, start with NVDA. It's free, open-source, and widely used. You can download it from nvaccess.org and be up and running in under five minutes.

If you're on a Mac, VoiceOver is already built in — press Command + F5 to toggle it on and off. On iOS, triple-click the Home button or Side button. On Android, use TalkBack.

But if you're choosing one to learn first, I recommend NVDA for a few reasons:

• It's free, so there's zero barrier to entry
• It pairs with Firefox, which has excellent accessibility support
• It's what a large portion of screen reader users on Windows actually use — WebAIM's screen reader survey consistently places NVDA among the most popular choices
• Its speech viewer panel lets you read what's being announced, which helps when you're still learning to process audio output

JAWS is the other major screen reader on Windows. It's commercial software with a licence fee, and it's what I use as my primary screen reader for professional work. If your organisation is serious about accessibility testing, having at least one JAWS licence is worth it — the two screen readers sometimes handle edge cases differently. But for getting started, NVDA is the right choice.

Essential Keyboard Shortcuts to Learn First

You don't need to memorise a hundred shortcuts. Start with these. They'll cover 80% of what you need for basic testing.

General Navigation

• Tab — Move to the next focusable element (links, buttons, form fields)
• Shift + Tab — Move to the previous focusable element
• Enter — Activate a link or button
• Space — Activate a button, check a checkbox, or toggle a control
• Escape — Close a dialog or menu
• Arrow keys — Navigate within menus, radio groups, tab panels, and other composite widgets

NVDA Browse Mode Quick Keys

When NVDA is in browse mode (which it enters automatically on web pages), you can use single letter keys to jump between elements:

• H — Next heading
• Shift + H — Previous heading
• 1 through 6 — Next heading at that level (e.g., 2 jumps to the next <h2>)
• F — Next form field
• B — Next button
• T — Next table
• K — Next link
• D — Next landmark
• G — Next graphic (image)

These quick keys are how I actually navigate the web. When I land on a page, I don't start reading from the top. I press H to skim the headings, get a sense of the page structure, and jump to the section I need. It's the screen reader equivalent of visually scanning a page. If your headings are missing or out of order, this navigation breaks down completely.

The Elements List

Press Insert + F7 in NVDA to open the Elements List. This gives you a filterable view of all headings, links, landmarks, and form fields on the page. It's the fastest way to audit your page structure. If your heading hierarchy looks wrong here, it will feel wrong to every screen reader user who visits.

What to Test — A Practical Checklist

Here's what I check on every page I test. This isn't an exhaustive WCAG audit — it's the set of things that, in my experience, have the biggest impact on whether a screen reader user can actually use your site.

1. Page Title and Landmarks

When I land on a page, the first thing my screen reader announces is the page title. If it says "Untitled" or just your domain name, I already have no idea where I am.

A good page title should be specific and follow a pattern like "Page Name | Site Name". Every page should have a unique, descriptive title.

Next, I check landmarks. These are the regions of the page that screen readers use for quick navigation: <header>, <nav>, <main>, <aside>, <footer>. When I press D in NVDA, I jump between these landmarks. If your page is just a pile of <div> elements with no semantic structure, I have no way to skip to the main content or find the navigation.

<div class="header">...</div>
<div class="nav">...</div>
<div class="content">...</div>
<div class="footer">...</div>

<header>...</header>
<nav aria-label="Primary">...</nav>
<main>...</main>
<footer>...</footer>

2. Heading Structure

Headings are the table of contents for screen reader users. I press H repeatedly to jump through them, or I open the Elements List to see them all at once. What I'm looking for:

• Is there exactly one <h1> that describes the page?
• Do the headings follow a logical hierarchy? (No jumping from <h2> to <h5>)
• Are headings used for structure, not just styling? (Don't make something an <h3> just because you want bold, smaller text)
• Does the heading sequence make sense if you read only the headings?

<h1>Welcome</h1>
<h4>Our Services</h4>
<h2>Contact Us</h2>
<h5>Address</h5>

<h1>Welcome to Acme Corp</h1>
<h2>Our Services</h2>
<h2>Contact Us</h2>
<h3>Address</h3>

3. Image Alt Text

When I navigate to an image, my screen reader reads the alt attribute. If it's missing, NVDA will often read the file name instead, which sounds something like "DSC underscore zero four seven two dot JPG." Not helpful.

Here's what to check:

• Informative images should have alt text that conveys the same information the image communicates visually
• Decorative images should have an empty alt attribute (alt="") so screen readers skip them entirely
• Images of text should have alt text that contains the same text shown in the image
• Complex images like charts or diagrams need a longer description, either in the alt text or in surrounding content

<img src="chart.png">
<img src="team.jpg" alt="image">
<img src="divider.png" alt="line">

<img src="chart.png" alt="Sales grew
  42% from Q1 to Q4 in 2025">
<img src="team.jpg" alt="The
  accessibility team at the 2025
  CSUN conference">
<img src="divider.png" alt="">

4. Form Labels and Error Messages

Forms are where accessibility breaks down most frequently. When I Tab to a form field, my screen reader should announce what that field is for. If I hear "edit blank" with no label, I'm guessing.

Here's what to check:

• Every input has a visible <label> element properly associated with it (using for and id)
• Required fields are indicated programmatically (aria-required="true" or the required attribute), not just with a visual asterisk
• When validation errors occur, the error message is associated with the relevant field (using aria-describedby)
• Focus moves to the first error or to an error summary after a failed submission
• Error messages are announced — not just displayed visually in red text

<input type="email"
  placeholder="Your email">
<span class="error"
  style="color: red">
  Invalid email
</span>

<label for="email">Email</label>
<input type="email" id="email"
  required
  aria-describedby="email-err">
<span id="email-err" role="alert">
  Please enter a valid email
</span>

5. Keyboard Navigation and Focus Order

Put your mouse away. Seriously. Unplug it if you have to. Now try to complete every task on your page using only the keyboard.

• Can you reach every interactive element with Tab?
• Can you see where focus is? (Is there a visible focus indicator?)
• Does focus move in a logical order that matches the visual layout?
• Can you operate every control? Buttons with Enter or Space, menus with Arrow keys, etc.
• Are there any keyboard traps where focus gets stuck and you can't Tab out?

When I encounter a keyboard trap, I'm stuck. I have to close the browser tab and start over. This happens more often than you'd think, especially in modal dialogs and embedded content.

6. ARIA Live Regions

When content changes dynamically on the page — a notification appears, a counter updates, search results load — screen reader users need to be told. We can't see the change happen visually. ARIA live regions solve this.

What to check:

• Do status messages (like "3 results found" or "Item added to cart") get announced?
• Are live regions present in the DOM before content is injected into them?
• Is aria-live="polite" used for non-urgent updates and aria-live="assertive" reserved for critical alerts?
• Do the announcements make sense in isolation, without visual context?

<!-- Live region must exist in DOM first, then content is injected -->
<div aria-live="polite" aria-atomic="true"></div>

<!-- After search completes, inject the message -->
<div aria-live="polite" aria-atomic="true">
  12 results found for "accessibility testing"
</div>

7. Modal Dialogs

Modals are one of the most commonly broken patterns I encounter. Here's what needs to happen for a modal to work with a screen reader:

• When the modal opens, focus moves into it — ideally to the first focusable element or the modal heading
• Focus is trapped inside the modal while it's open (Tab cycles within the modal, not behind it)
• The modal has a role of dialog and an accessible name (via aria-labelledby pointing to its heading)
• Pressing Escape closes the modal
• When the modal closes, focus returns to the element that triggered it

I test dozens of modals every month. I'd estimate that fewer than half of the custom-built modals I encounter get all five of these right. Use the native <dialog> element when you can — it handles most of this for you.

8. Tables

Data tables need proper markup so screen readers can associate cells with their headers. When I navigate a table, NVDA announces the column header as I move between cells. Without proper headers, I just hear disconnected values with no context.

<table>
  <tr>
    <td><b>Name</b></td>
    <td><b>Role</b></td>
  </tr>
  <tr>
    <td>Akhilesh</td>
    <td>Architect</td>
  </tr>
</table>

<table>
  <caption>Team Members</caption>
  <thead>
    <tr>
      <th scope="col">Name</th>
      <th scope="col">Role</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Akhilesh</td>
      <td>Architect</td>
    </tr>
  </tbody>
</table>

If you're using a table for layout rather than data, add role="presentation" so screen readers don't try to interpret it as a data table. Better yet, don't use tables for layout at all — use CSS.

Common Mistakes Beginners Make

Turning It Off Too Soon

The most common mistake I see is someone launching a screen reader, getting overwhelmed by the audio, and closing it within 30 seconds. I understand the impulse. When you first hear a screen reader, it's a wall of sound. It talks fast, it reads things you didn't expect, and you have no idea what's happening.

Push through. Give yourself at least 15 minutes per session. Slow the speech rate down (in NVDA, press Insert + Ctrl + Down Arrow to decrease speed). Turn on the Speech Viewer. It will start to make sense. I've been using screen readers for over 16 years and I promise you: the learning curve is steep at the start, but it flattens quickly.

Relying on Visual Memory

Here's a subtle trap: you already know what your page looks like. When the screen reader announces "button," you think "oh, that's the submit button" because you can see it. A real screen reader user doesn't have that context. They only know what the screen reader tells them.

Try testing with your monitor off, or at least look away from the screen. Force yourself to rely only on what you hear. It's uncomfortable. That's the point.

Skipping Keyboard-Only Testing

Screen reader testing and keyboard-only testing are related but different. Some issues are keyboard problems, not screen reader problems. Test both separately. Tab through your entire page without a screen reader first. Then do it again with one.

Testing Only the Happy Path

Don't just test the page in its default state. Submit a form with errors. Open and close dialogs. Load more content. Use the back button. Try the page at different zoom levels. Real users don't follow the script.

Assuming One Screen Reader Is Enough

NVDA and JAWS don't always behave identically. VoiceOver on Safari handles certain ARIA attributes differently than NVDA on Firefox. If you can only test with one, start with NVDA and Firefox. But be aware that what works in one combination might not work in another.

The Difference Between "Accessible" and "Usable"

This is something that took me years to articulate, but it's the most important thing in this entire article.

A page can be technically screen reader accessible — every element has the right roles, labels, and attributes — and still be miserable to use. Technically, a screen reader can read it. Practically, no one would want to.

Here's what I mean. I've tested e-commerce sites where every product had alt text, every button had a label, every form was properly marked up. But to add a single item to my cart, I had to navigate through 47 elements. The page had no heading structure, so I couldn't skip to the content I needed. There were no landmarks, so I had to read through the entire navigation, promotional banners, and sidebar before reaching the product listing.

Technically accessible? Yes. Usable? Absolutely not.

Accessibility is the floor. Usability is the goal. If a sighted user can complete a task in 10 seconds and a screen reader user needs 5 minutes for the same task, you have an accessibility problem — even if every automated check passes.

Usability means:

• Efficient navigation through well-structured headings and landmarks
• Clear, concise labels that don't force me to listen to a paragraph before I know what a button does
• Logical reading order that matches the visual flow
• Meaningful feedback for every action I take
• Skip links so I can bypass repeated content

When I audit a site, I don't just check if things are technically correct. I ask: can I use this efficiently? Can I accomplish my goal in a reasonable amount of time? That's the standard.

Start with 30 Minutes a Week

I'm not asking you to become a screen reader expert overnight. I'm asking you to spend 30 minutes a week with one. Here's how I'd structure it:

1. Week 1: Install NVDA. Open your own website. Just listen. Don't try to fix anything yet. Just hear what it sounds like.
2. Week 2: Learn the heading navigation (H key) and the Elements List (Insert + F7). Check your heading structure on two or three pages.
3. Week 3: Test your forms. Tab through every form field. Submit with errors. Listen to what gets announced and what doesn't.
4. Week 4: Test your interactive components. Open a modal, use a dropdown, navigate a tab panel. Check if keyboard and screen reader support are complete.

After a month of this, you'll catch problems you never knew existed. After three months, you'll start hearing issues instinctively. After six months, you'll wonder how you ever shipped code without testing this way.

If you've run into issues you're not sure how to fix, or if you want help building screen reader testing into your team's workflow, reach out. This is what I do every day, and I'm always glad to help teams build better habits.