You can test your website with a screen reader today, with software you already have, in about half an hour per page. On Windows, install NVDA and pair it with Chrome. On a Mac, press Command-F5 to start VoiceOver and switch to Safari (Apple). Then do one thing: turn the monitor off and try to finish a real task on the page, like signing up or getting through checkout. Eight or so keyboard commands will carry you through it. You do not need the manual.
The reason to bother is that this covers the half a scanner cannot reach. Automated tools catch roughly 30 to 57% of issues depending on how you count them (Deque). What is left turns on meaning: whether the alt text says anything true, whether the tab order follows the page, whether a failed form tells anyone it failed. A screen reader surfaces that in minutes.
What it will not give you is a conformance verdict, and it will not turn you into a screen reader user. This guide covers which one to pick, the commands worth learning, what to check on a page, and where your own testing stops.
Which screen reader should I test with?
Start with NVDA on Windows and VoiceOver on macOS. Both are free, and between them they cover most of what your users run.
WebAIM's tenth Screen Reader User Survey, run across 1,539 respondents in December 2023 and January 2024, found JAWS is the primary desktop screen reader for 40.5% of users and NVDA for 37.7%, with VoiceOver at 9.7% (WebAIM). Ask instead which screen readers people use at all, rather than which one they call primary, and NVDA comes out on top at 65.6% against JAWS at 60.5%.
Browser pairing matters more than people expect, because the bug often lives in the combination rather than in either piece. The most common pairings in the same survey were JAWS with Chrome (24.7%), NVDA with Chrome (21.3%), and JAWS with Edge (11.4%). WebAIM's own guidance is that VoiceOver works best with Safari, which is why the Mac instructions above say Safari and not Chrome (WebAIM).
Do not skip mobile. 91.3% of respondents use a screen reader on a phone or tablet, VoiceOver on 70.6% of them and TalkBack on 34.7%. If your signup flow lives on phones, test it there.
How do I start NVDA or VoiceOver?
NVDA installs from NV Access and starts with Ctrl + Alt + N. To quit it, press NVDA + Q. The NVDA modifier key is Insert by default, though WebAIM suggests setting Caps Lock as the modifier during install, which is easier on a laptop (WebAIM).
The one NVDA concept worth knowing first is the mode split. In browse mode you read the page and single letter keys jump between elements. In focus mode your keystrokes go to the control instead, so you can type in a text field. NVDA switches automatically when focus lands on an input, and a high-pitched beep tells you it happened. NVDA + Space toggles it by hand. Most first-session confusion comes from pressing H for headings while focus mode is on and watching an "h" appear in the search box.
VoiceOver needs no install. Command-F5 turns it on, and the same keys turn it off. The VoiceOver modifier, written VO in every guide, is Control + Option held together, or Caps Lock if you prefer (Apple). One setting to change before you test: in Safari, enable "Press Tab to highlight each item on a webpage", or Tab will skip past everything that is not a form field.
One practical note: turn the speech rate down before your first session. The default is tuned for people who read at speed, and to a beginner it is noise.
Which screen reader commands do I actually need?
Fewer than you think. This set gets you through a page:
| What you want | NVDA (browse mode) | VoiceOver (Safari) |
|---|---|---|
| Read from here | NVDA + ↓ | VO + A |
| Stop talking | Ctrl | Control |
| Next heading | H (or 1–6 for a level) | VO + Command + H |
| Next link | K | VO + Command + L |
| Next form field | F | VO + Command + J |
| Next landmark | D | VO + U, then arrow to Landmarks |
| List everything on the page | NVDA + F7 | VO + U (rotor) |
| Activate the thing you are on | Enter | VO + Space |
Those come from WebAIM's NVDA and VoiceOver references and Apple's VoiceOver guide (WebAIM, Apple). Learn the read-all key and the stop key first; look the rest up mid-session.
What should I check on the page?
Work through the page in this order. Each step exposes a class of failure that a scan either misses or cannot judge.
Tab through it with your eyes open first. Watch where the focus ring goes. If it disappears behind a sticky header, jumps from the logo to the footer, or vanishes entirely on your custom dropdown, you have found a problem before the speech even matters. That is WCAG 2.4.3 Focus Order and 2.4.7 Focus Visible (W3C).
Pull up the heading list. NVDA + F7, or VO + U and arrow to Headings. It should read like a table of contents for the page. A marketing page whose only h1 is the site name, with every section title built from a styled <div class="section-title">, produces a list with nothing in it. The page looks structured and is not.
Press D for landmarks. You want banner, navigation, main, and contentinfo. When <main> is missing, a skip link has nothing to skip to, and a screen reader user has no way to jump past your navigation on every page load.
Listen to the images. This is where scanners are the weakest, because an alt attribute that exists passes the automated check whatever it contains. Hearing "graphic, hero-banner-final-v2-dot-png" tells you in one second what a green checkmark in a report never will. WCAG 1.1.1 asks for a text alternative that serves the equivalent purpose, and only a person can judge equivalence.
Tab into every form field. You should hear the label, the type of control, and any instruction, in that order: "Email address, edit text, required". If you hear "edit text, blank", the label is not wired to the input and the placeholder is doing work it cannot do. Then submit the form with something wrong in it, and listen. Plenty of forms paint an error message in red and announce nothing at all, which fails 3.3.1 Error Identification even though the message is visibly on screen (W3C).
Poke the custom widgets. A <div> with a click handler announces as nothing and cannot be reached by Tab. A real <button> announces "Submit, button". Anything you built yourself, a modal or a combobox, is where 4.1.2 Name, Role, Value quietly breaks.
Then turn the screen off and finish the task. Buy something, or sign up. This is the step that finds barriers no checklist predicted, and the only one that answers the question a customer actually asks.
What will a screen reader test not tell you?
It will not tell you that your site conforms. The W3C is direct about the limits of a quick pass: "A web page could seem to pass these checks, yet still have significant accessibility barriers" (W3C WAI). Your session covers the pages you visited, with one screen reader, in one browser.
It will also not tell you what the experience is like for someone who uses this software every day. You are a slow and clumsy operator of a tool that experienced users drive at speeds you would find unintelligible. Things that frustrate you may be routine for them, and things you shrug off may end the task. That gap is why W3C WAI recommends evaluating with real users: doing so "identifies usability issues that are not discovered by conformance evaluation alone", and it notes that even a person with a disability "does not necessarily know how other people with the same disability interact with the web" (W3C WAI).
Here is my position after doing a lot of these sessions: a developer with a screen reader finds bugs, not verdicts. That is still worth an enormous amount, because the bugs are real and cheap to fix once you have heard them. It just means the output of your afternoon is a defect list, not a compliance claim. Anyone selling you a script that removes this step is selling the thing the US Federal Trade Commission ordered accessiBe to pay $1 million over, after finding it misrepresented what its automated product could do (FTC).
How does this fit into EAA and EN 301 549 compliance?
Manual testing is how you honestly fill in the criteria a machine cannot assess. Under the European Accessibility Act, the technical bar for in-scope digital products comes from EN 301 549, whose web clause incorporates WCAG at Level AA. Annex C of that standard walks through the requirements one at a time so you can record each as met, not met, or not applicable. For the criteria that hinge on judgement, such as whether alt text is equivalent or whether an error message helps, a screen reader session is the evidence behind whatever you write down.
The same logic holds in the US. The Department of Justice picked WCAG 2.1 Level AA as the technical standard for state and local government web content and mobile apps under ADA Title II (ADA.gov). Your testing also feeds the accessibility statement you publish, which documents the effort you made and the limitations you know about, rather than promising a result.
Frequently asked questions
Which screen reader should I use to test my website?
NVDA with Chrome on Windows and VoiceOver with Safari on macOS. Both are free, and WebAIM's survey found NVDA is the most widely used desktop screen reader overall at 65.6% of respondents, with JAWS the most common primary one at 40.5% (WebAIM). Test on a phone too, since 91.3% of respondents use a mobile screen reader.
Can I test with a screen reader if I have never used one?
Yes, and you will find real problems on your first attempt. Learn the read-all command, the stop key, and heading navigation, then try to complete a task with the screen off. Just treat the result as a defect list rather than a judgement about how usable your site is for daily screen reader users.
How long does a screen reader test take?
Budget about 30 minutes for a single page once the software is installed, and longer for a multi-step flow like checkout. Your first session runs slower because you are still learning the commands.
Do I still need automated scanning if I test manually?
Yes, and mostly for the arithmetic. Automation covers roughly 30 to 57% of issues by volume (Deque) and does it across every page, which no person can do by hand. Manual testing then goes where the machine has no opinion.
Does passing a screen reader test mean my site is accessible?
No. It means the paths you tested worked with the screen reader and browser you used. Full conformance needs coverage across your whole site plus review by someone who knows the success criteria.
Find the machine-detectable issues first
Screen reader time is expensive, so do not spend it on missing labels and empty links a scan finds in seconds. Run a free scan to clear the automated list, then take a screen reader through your signup or checkout flow and work the WCAG checklist for the judgement calls. Automation gives you the inventory. The screen reader tells you whether anyone can get through.
Pavel Charkasau, founder, wcagc.com. Last updated 25 August 2026.
Sources
- Screen Reader User Survey #10 Results, WebAIM — 1,539 respondents, December 2023 to January 2024; primary and overall screen reader usage, browser pairings, mobile usage. Accessed 25 August 2026.
- Using NVDA to Evaluate Web Accessibility, WebAIM — starting and quitting NVDA, the modifier key, browse and focus modes, the element navigation keys and Elements List. Accessed 25 August 2026.
- Using VoiceOver to Evaluate Web Accessibility, WebAIM — VO keys, the rotor, heading and form navigation, and the Safari pairing. Accessed 25 August 2026.
- Turn VoiceOver on or off on Mac, Apple — Command-F5 toggles VoiceOver. Accessed 25 August 2026.
- Get started with VoiceOver on Mac, Apple — the VO modifier is Control-Option or Caps Lock. Accessed 25 August 2026.
- Use the VoiceOver rotor on Mac, Apple — VO-U opens the rotor and arrow keys change category. Accessed 25 August 2026.
- Easy Checks: A First Review of Web Accessibility, W3C WAI — a page can pass quick checks and still have significant barriers. Accessed 25 August 2026.
- Involving Users in Evaluating Web Accessibility, W3C WAI — user evaluation finds usability issues conformance evaluation misses. Accessed 25 August 2026.
- Understanding SC 2.4.3: Focus Order, W3C — focus order must preserve meaning and operability. Accessed 25 August 2026.
- Understanding SC 3.3.1: Error Identification, W3C — input errors must be identified and described in text. Accessed 25 August 2026.
- Automated testing identifies 57% of accessibility issues, Deque — automated coverage by issue volume against the 20–30% criteria benchmark. Accessed 25 August 2026.
- FTC approves final order requiring accessiBe to pay $1 million, Federal Trade Commission — deceptive claims about an automated accessibility product. Accessed 25 August 2026.