Testing Guide • Updated July 2026

NVDA Screen Reader Testing: The Complete Guide

NVDA is the free Windows screen reader you should test with first. This guide takes you from install to a repeatable testing workflow — browse vs focus mode, the NVDA modifier key, the Elements List, and a full keyboard command cheat sheet — with every finding mapped to WCAG 2.2 AA.

Why Test with NVDA

A screen reader turns the visual interface into speech and braille. It reads out headings, links, buttons, form labels, and status messages, and lets the user navigate by those structures instead of by sight. If your markup is wrong — a button with no name, an image with no alt text, an update that never announces — the screen reader has nothing meaningful to say, and the feature is unusable no matter how good it looks.

NVDA (NonVisual Desktop Access) is free, open source, and one of the two most used desktop screen readers in the world. Because it costs nothing to install, it is the most practical way for any developer or QA engineer to hear their site the way a screen reader user does. Automated scanners like axe and WAVE catch roughly a third of issues; the rest — does this actually make sense when read aloud? — needs a human listening with a real screen reader. This guide is the NVDA-specific companion to our broader screen reader testing guide, which also covers JAWS, VoiceOver, and TalkBack.

1. Install & Configure NVDA

NVDA runs on Windows only. Download it from the NV Access website and install it — the installer is small and the whole process takes a couple of minutes. A few settings make testing far easier, so configure them before you start.

Download and install. Get NVDA from nvaccess.org/download. On the welcome dialog, tick Use CapsLock as an NVDA modifier key if you are on a laptop without a convenient Insert key.
Enable the Speech Viewer. Open the NVDA menu with NVDA+N, go to Tools → Speech Viewer. This shows everything NVDA speaks as on-screen text — invaluable for sighted testers who want to read along and copy exact announcements into a bug report.
Pick a test browser. Use Firefox or Chrome, the two browsers NV Access supports best. Test in both when you can.
Learn the stop key. Press Ctrl at any time to silence speech. You will use it constantly.

Note: NVDA is a Windows application. To test the same pages with a screen reader on macOS or mobile, see VoiceOver and TalkBack in the screen reader testing guide.

2. Browse Mode vs Focus Mode — the One Thing to Understand

NVDA reads web pages in one of two modes, and knowing which mode you are in explains most of what you hear. Getting this right is the single most important skill for testing.

Browse mode (default)

For reading. A virtual cursor moves through the page and single-key shortcuts navigate by structure.

H jumps to the next heading
K to the next link, F to the next field
Arrow keys read line by line

NVDA plays a low beep when it switches into browse mode.

Focus mode

For interacting. Keystrokes pass straight to the control so you can type or use arrow keys inside a widget.

Typing goes into the text input
Arrows move within a listbox or menu
Single-key shortcuts are turned off

NVDA plays a higher beep when it switches into focus mode.

NVDA switches automatically: it enters focus mode when you Tab to or click an editable field or an application-style widget, and drops back to browse mode when you move away. You can also toggle manually with NVDA+Space. Listen for the two distinct beeps — they tell you which mode you are in.

Many screen reader bugs are really mode bugs. If a custom dropdown never enters focus mode, its arrow keys get swallowed by browse mode and the user cannot select an option. If a widget traps you in focus mode with no way back, you cannot use the single-key navigation to escape. When something feels stuck, the first question is always: what mode is NVDA in, and is that the right one for this control? The cleanest fix is to build on native, keyboard-operable elements so the mode switch just works.

3. Essential NVDA Keyboard Commands (Cheat Sheet)

NVDA below means the NVDA modifier key — Insert by default, or CapsLock if you enabled it. Single letters like H and K only work in browse mode. These twenty commands cover almost everything you need to test a web page.

Essential NVDA keyboard commands and what each one does
Command	What it does
`NVDA+N`	Open the NVDA menu (settings, tools, help)
`NVDA+Q`	Quit NVDA
`Ctrl`	Stop speech immediately
`NVDA+↓ (or NVDA+A)`	Say all — read continuously from the cursor
`↑ / ↓`	Read previous / next line (browse mode)
`Tab / Shift+Tab`	Move to next / previous focusable control
`H / Shift+H`	Next / previous heading
`1 – 6`	Next heading of level 1 through 6
`K / Shift+K`	Next / previous link
`F / Shift+F`	Next / previous form field
`B / Shift+B`	Next / previous button
`D / Shift+D`	Next / previous landmark region
`T / Shift+T`	Next / previous table
`L / Shift+L`	Next / previous list
`G / Shift+G`	Next / previous graphic (image)
`NVDA+F7`	Elements List — all headings, links, landmarks, form fields
`NVDA+Space`	Toggle browse mode and focus mode manually
`NVDA+Tab`	Announce the currently focused control
`NVDA+T`	Read the title of the current window / page
`Enter / Space`	Activate the current link or control

The full command set lives in the built-in help — press NVDA+N then choose Help. To learn what any key does without triggering it, turn on Input Help with NVDA+1 and press keys freely; press NVDA+1 again to turn it off.

4. Audit Structure with the Elements List

Press NVDA+F7 to open the Elements List. It shows every heading, link, form field, button, and landmark on the page, with radio buttons to switch between them. This is exactly how a screen reader user surveys an unfamiliar page, so it is the fastest structural audit you can run.

Headings. Confirm there is exactly one <h1>, that levels do not skip (an <h2> is not followed by an <h4>), and that the outline reads like a table of contents. Maps to 1.3.1 Info and Relationships.
Links. Every link should make sense on its own — no bare “click here” or “read more” repeated a dozen times (2.4.x link purpose).
Landmarks. Look for banner, navigation, main, and contentinfo so users can jump between page regions with D.
Form fields. Each should announce a clear label, not “edit blank.” Cross-check with the accessible forms guide.

5. A Repeatable NVDA Testing Workflow

Run this pass on every key page or flow. Keep the Speech Viewer open so you can copy exact wording into your notes.

Read the page title. Press NVDA+T. It should be unique and describe the page, not just the site name.
Survey the structure. Open the Elements List (NVDA+F7) and review headings, then links, then landmarks.
Read it all. Press NVDA+↓to have NVDA read from the top. Note anything that sounds wrong — an image reading its file name, a button that says only “button,” text in the wrong order.
Tab through interactive controls. Every link, button, and field should announce a name and a role. Confirm focus mode engages on inputs and custom widgets.
Operate each widget. Open menus, toggle disclosures, use custom selects. Arrow keys should move within them and the state (expanded, selected) should be spoken.
Trigger dynamic changes. Submit a form with an error, add to cart, filter a list. NVDA should announce the change without you moving focus — that is 4.1.3 Status Messages.
Check modals and focus. When a dialog opens, focus should move into it and be trapped; closing should return focus to the trigger. See the focus management guide.

Common NVDA Findings & How to Fix Them

These are the problems NVDA surfaces most often. Each one is a real WCAG failure that automated tools frequently miss or can only partially detect.

Common problems found when testing with NVDA, why they fail, and the fix
What you hear	Why it fails	The fix
A button that NVDA announces only as "button" with no name.	No accessible name — the user cannot tell what it does (WCAG 4.1.2).	Give it visible text, aria-label, or aria-labelledby.
An image that reads its file name, e.g. "IMG 4021 dot jpg graphic".	Missing or meaningless alt text conveys nothing (WCAG 1.1.1).	Add concise alt describing purpose; use empty alt="" for decoration.
A form field that speaks as "edit blank" with no label.	Unlabeled input — the user does not know what to type (WCAG 1.3.1, 4.1.2).	Associate a <label> with for/id, or use aria-label.
A custom dropdown you can Tab to but not open or arrow through.	Focus mode never engages or keys are swallowed (WCAG 2.1.1).	Use native <select>, or add correct role, state, and key handlers.
A cart count or error that updates visually but NVDA stays silent.	Dynamic change is not announced (WCAG 4.1.3 Status Messages).	Put the update in an aria-live="polite" (or role="alert") region.
Every link on the page reads simply "click here" or "read more".	Link purpose is unclear out of context in the Elements List (WCAG 2.4.4).	Write descriptive link text that makes sense on its own.

Fixing most of these comes down to correct roles, names, and states — the domain of the ARIA roles & attributes reference. Verify names and roles programmatically under 4.1.2 Name, Role, Value.

What NVDA Testing Verifies in WCAG 2.2

WCAG 2.2 success criteria you can verify by testing with NVDA
Criterion	Level	What NVDA reveals
1.1.1 Non-text Content	A	Images announce meaningful alt text, not file names.
1.3.1 Info and Relationships	A	Headings, lists, and tables convey real structure.
2.1.1 Keyboard	A	Every control is reachable and operable via the keyboard.
4.1.2 Name, Role, Value	A	Controls announce an accessible name, role, and current state.
4.1.3 Status Messages	AA	Dynamic updates are announced without moving focus.

See the full picture in the WCAG 2.2 Level AA requirements and track your coverage with the WCAG 2.2 checklist.

NVDA vs JAWS in brief

NVDA is free and open source; JAWS is commercial.
Both are Windows-only and heavily used in the wild.
Commands overlap but differ — do not assume identical behavior.
Test with both when you can; start with NVDA.

Broader comparison in the screen reader testing guide.

Test the keyboard first

A screen reader relies on the keyboard working.
If Tab cannot reach a control, NVDA cannot either.
Fix keyboard operability before chasing speech bugs.

Start with the keyboard accessibility guide.

NVDA Testing Checklist

Setup. NVDA installed, Speech Viewer open, testing in Firefox and Chrome, NVDA modifier key set.
Title & structure. Unique page title; one <h1>; heading levels do not skip; landmarks present.
Names & roles. Every link, button, and field announces a clear name and its role — no “button” or “edit blank.”
Images. Meaningful images have descriptive alt; decorative images are silent (alt="").
Mode switching. Focus mode engages on inputs and custom widgets; you can always get back to browse mode.
Dynamic updates. Errors, cart counts, and filter results are announced via live regions.
Dialogs. Focus moves into modals, is trapped, and returns to the trigger on close.

Scan Before You Listen

Automated scanning clears the obvious issues so your NVDA time is spent on the problems only a human can hear. Run a free axe-core scan first, then work through the NVDA pass above.

Scan a Page Now Screen Reader Testing Guide

Frequently Asked Questions

Is NVDA free, and why test with it?▾

Yes. NVDA (NonVisual Desktop Access) is a free, open-source screen reader for Windows, developed by NV Access. It is one of the two most widely used desktop screen readers in the world alongside JAWS, and because it costs nothing it is the most accessible way for developers and QA teams to test with a real screen reader. Testing with NVDA reveals problems automated scanners cannot detect — unlabeled controls that speak as blank, headings that do not convey structure, dynamic updates that are never announced, and custom widgets that a keyboard user cannot operate. If you can only install one screen reader for testing on Windows, install NVDA.

What is the difference between browse mode and focus mode in NVDA?▾

Browse mode (the default on web pages) lets you read a page like a document: single-key shortcuts such as H for headings, K for links, and the arrow keys move a virtual cursor through the content without activating anything. Focus mode is for interacting with form fields and custom widgets: keystrokes pass straight through to the control so you can type into an input or use arrow keys inside a listbox. NVDA switches between them automatically — it enters focus mode when you Tab to or click an editable field or an application widget, and returns to browse mode when you leave. You can toggle manually with NVDA+Space. Understanding this switch is the single most important skill for testing with NVDA, because many bugs are really a mode problem: a widget that traps you in the wrong mode, or one that never enters focus mode at all.

What is the NVDA modifier key?▾

The NVDA modifier (written as NVDA in command lists) is the key you hold with other keys to issue NVDA commands. By default it is Insert, and you can also use the numeric keypad Insert. On laptops without a convenient Insert key, enable Caps Lock as an additional NVDA key during installation or in Settings, Keyboard. So a command written as NVDA+F7 means Insert+F7 (or CapsLock+F7 if you enabled it). Configuring Caps Lock as the modifier is the most common setup for laptop testing.

Which browser should I use to test with NVDA?▾

Use Mozilla Firefox or Google Chrome. NV Access develops and tests NVDA primarily against Firefox and Chrome, and they have the most reliable accessibility support with NVDA. Firefox has historically been the reference pairing for NVDA and is a safe default. Test in Chrome as well, since it is the most common browser your users will actually have. Avoid drawing conclusions from a single browser: a bug that only appears in one pairing is worth noting, but real accessibility failures usually reproduce across both.