Ask a room full of designers, developers, and product managers who built a website whether they have ever turned on a screen reader and used their own product with it. Most hands stay down. People who spend years shipping interfaces have often never heard their own homepage read aloud, never once tabbed through their own checkout flow with their eyes closed.
That gap is not a character flaw. Screen readers feel intimidating from the outside: unfamiliar keyboard shortcuts, a voice that talks faster than you can follow, a sense that you need weeks of training before you are "allowed" to test anything. None of that is true. You need about 20 minutes and a willingness to feel a little lost for the first five of them.
This guide walks you through exactly those 20 minutes. No prior experience required, no special equipment beyond the computer you already have. By the end, you will have a repeatable routine you can run on any page, any time, before or after a release.
The Stat: An estimated 1.3 billion people, about 16% of the global population, experience significant disability. (Source: World Health Organization)
Step 1: Turn on the screen reader (2 minutes)
You do not need to install anything unusual. Both major operating systems ship a screen reader for free.
On a Mac: press Command + F5 to toggle VoiceOver on and off. A quick startup chime and a black rectangle called the VoiceOver cursor will appear around whatever is focused.
On Windows: download NVDA, a free, open source screen reader maintained by NV Access. Install it, launch it, and it starts speaking immediately.
Before you touch your own site, spend thirty seconds getting oriented. Open a blank browser tab and press Tab a few times. Notice that the screen reader announces the element type ("link," "button," "edit text") along with its label. That pairing, element type plus label, is the core unit of information a screen reader user relies on for every single interaction. Keep that in mind as you move forward: if either half is missing or wrong, the experience breaks.
Turn your monitor off, or simply close your eyes, once you feel steady. You will learn far more by listening than by watching the screen and reading along, because reading along lets your eyes cheat for information your ears should be catching on their own.
Step 2: Navigate by headings (5 minutes)
Now open the page you actually want to test. Instead of reading top to bottom, do what an experienced screen reader user does first: skim the page's structure using headings.
- On VoiceOver, press Control + Option + Command + H to jump to the next heading.
- On NVDA, press the H key on its own to jump to the next heading, or 1 through 6 to jump to a heading of a specific level.
As you move heading to heading, ask yourself three questions:
- Does the sequence make sense on its own? If someone heard only the headings, in order, with nothing else, would they understand what this page is and how it is organized?
- Is there exactly one heading that describes the main content? Multiple competing "main" headings, or none at all, leave a screen reader user without an anchor point.
- Are headings used for structure, not styling? A line of bold text that is visually large but not marked up as a heading is invisible to this navigation method entirely, even though a sighted user would read it as a section title.
This single technique, jumping by heading, is one of the fastest ways to judge whether a page respects the structure a screen reader user depends on to skip past repeated content and get straight to what matters. The W3C's guidance on bypassing repeated blocks explains exactly why this matters: without a way to jump past navigation and boilerplate, every single page load becomes a slow, repetitive slog before the actual content is even reached.
Step 3: Tab through the interactive elements (8 minutes)
This is where most of the real problems live, and it deserves the largest share of your 20 minutes.
Put your mouse aside entirely. Using only the Tab key (and Shift + Tab to go backward), move through every link, button, form field, and control on the page, one at a time. For each stop, listen for two things: what the screen reader announces, and whether you can tell, just from that announcement, what will happen if you activate it.
Watch out for these common failures, all of which are well documented, real patterns you will likely encounter on almost any site you have not specifically audited:
- Unlabeled buttons. An icon-only button for search or menu that gets announced as just "button," with no indication of what it does.
- Ambiguous link text. A row of "Read more" or "Click here" links that all sound identical, giving no way to tell them apart out of context.
- Missing form labels. An input field that is announced as "edit text" with no name, leaving a screen reader user guessing what information belongs there.
- Focus that jumps somewhere unexpected. Opening a modal or menu that does not move focus into it, so you keep tabbing through a background page you can no longer see.
- Focus that disappears. A custom dropdown or carousel where, after an interaction, the visual focus indicator and the screen reader's read position are no longer in the same place.
WebAim's reference on writing meaningful hypertext is a good practical companion here. It lays out, in concrete terms, what makes link text usable versus what leaves a listener guessing. Keep it open in another tab while you work through this step.
If you have already run a keyboard-only pass on your site, this step will feel familiar, and that is intentional. Our five-minute keyboard test is the fast, lightweight version of this same idea: no screen reader needed, just your keyboard and your eyes, to catch the most obvious traps in a few minutes. Screen reader testing goes a layer deeper, because it also tells you whether what is announced out loud actually matches what a sighted keyboard user sees on screen.
Step 4: Try one real task, start to finish (5 minutes)
Reading through elements one at a time is useful, but it does not tell you whether someone can actually get anything done on your site. For your final five minutes, pick one real, meaningful task and complete it entirely with the screen reader still running: search for a product, fill out a contact form, sign up for a newsletter, or add something to a cart.
Do not stop halfway because it got difficult. Push through to the end, the same way a real visitor would have to. This is usually the moment a team's assumptions about their own product change the most, because a page can pass every individual element check and still add up to a task that is confusing or impossible to finish in practice.
If you want to see what this looks like taken all the way to its logical conclusion, on a real storefront, with real friction points and real fixes, read our account of rebuilding a Shopify store's checkout with a screen reader on. It is the long-form version of exactly this fourth step, applied to one of the highest-stakes flows on any commerce site.
What to do with what you just learned
Twenty minutes will not surface every issue on a complex site, and it is not a substitute for a full audit. What it will do is give you, personally, a felt sense of what your product asks of a blind or low-vision visitor every single day. That felt sense tends to stick. Teams that run this test once, even informally, start noticing missing labels and confusing link text in code review without anyone having to tell them to look.
Make it a habit rather than a one-time exercise. Run it on any page before it ships, especially anything involving a form, a modal, or a custom interactive component, since those are exactly the places default browser behavior gets overridden and screen reader support has to be rebuilt deliberately.
If this quick pass turns up more than you know how to fix, or you would rather have a second set of trained ears confirm what you found, our free tools are a good next step, and they are built to complement exactly this kind of hands-on testing rather than replace it.
Get help from a person
If you get partway through this test and hit something you are not sure how to interpret, or you want a professional to walk through your specific site with you, reach out to our team directly at experts@wcag.world. You can also start with our free tools to get a quick read on where your site stands before you talk to anyone.