NVDA screen reader testing notes are the working record an auditor keeps while evaluating a page or screen with NVDA. The notes capture what was announced, what was missed, what was misordered, and what blocked task completion. They include the browser used, the NVDA version, the page or component evaluated, the key sequence tried, and the actual output spoken. Strong notes tie each observed issue to a specific WCAG success criterion so the audit report writes itself. NVDA is paired with Firefox or Chrome on Windows during evaluation, and notes are recorded in real time rather than reconstructed afterward.
| Element | What to Record |
|---|---|
| Environment | NVDA version, browser, OS, page URL, date evaluated |
| Action | Key sequence used (Tab, H, K, Insert+F7, etc.) |
| Expected output | What an accessible interface should announce |
| Actual output | Exactly what NVDA announced, in quotes |
| WCAG mapping | Success criterion the issue maps to (e.g., 1.3.1, 4.1.2) |
| Severity | Blocker, major, moderate, minor |
Why NVDA Notes Matter in an Audit
An accessibility audit identifies issues against WCAG. Screen reader output is direct evidence. When NVDA reads a button as “button” with no accessible name, that single observation supports a 4.1.2 issue with no ambiguity.
Notes also protect the audit from drift. A page evaluated on Monday and revisited on Friday should produce the same recorded observations. Without notes, the auditor is reconstructing from memory, which weakens the report.
Setting Up Before You Take Notes
Confirm the environment before the first keystroke. Record the NVDA version (Insert+N, then Help, About), the browser version, and the operating system. Set NVDA to speak punctuation at the level needed for the page being evaluated, usually “some” or “most.”
Turn on speech viewer (Insert+N, Tools, Speech Viewer). The viewer shows a running transcript of what NVDA announces, which makes it easier to capture exact wording for the notes.
What Key Commands Should You Document?
The audit covers reading, navigation, and interaction. The notes should reflect the same range. Tab and Shift+Tab move through interactive elements. H and Shift+H move by heading. K and Shift+K move by link. F and Shift+F move by form field. R and Shift+R move by region or landmark. Insert+F7 opens the elements list. Down arrow in browse mode reads line by line. Insert+Down arrow triggers say all.
Capture the command used, the element reached, and the announcement. If a heading hierarchy skips from H2 to H4, the notes show the H key sequence and the announced levels.
Recording Actual Output Verbatim
Quote NVDA exactly. “Graphic” is different from “Graphic, submit.” “Edit blank” is different from “Edit, email, required.” The auditor’s interpretation goes in a separate column. The announcement column stays literal.
If NVDA says nothing when focus moves to an element, write “silent” or “no announcement.” Silence is data.
Mapping Observations to WCAG
Each note should carry a success criterion. Common mappings during NVDA evaluation: unlabeled controls or icons spoken as “button” or “graphic” alone map to 4.1.2 Name, Role, Value. Form fields without programmatic labels map to 1.3.1 Info and Relationships and 3.3.2 Labels or Instructions. Headings out of order or missing map to 1.3.1 Info and Relationships. Status messages not announced map to 4.1.3 Status Messages. Focus order that does not follow visual order maps to 2.4.3 Focus Order. Keyboard traps in custom widgets map to 2.1.2 No Keyboard Trap.
This mapping is what turns notes into an audit report. The auditor identifies the issue, cites the criterion, and references the recorded announcement as evidence.
Common Patterns Worth Flagging
Custom dropdowns built with div and span often announce as “clickable” with no role. Modal dialogs frequently open without moving focus, leaving NVDA stuck on the trigger button. Toast notifications appear visually but never reach the screen reader because they lack a live region. Image carousels read every slide regardless of visibility, flooding the user with content.
Each of these patterns is recognizable from the NVDA output alone, which is why the verbatim record is so useful.
Notes vs. Scans
Automated scans flag approximately 25% of issues and cannot evaluate screen reader output at all. A scan can detect a missing alt attribute. It cannot tell you that the alt text on a logo says “logo logo logo” because the file name was duplicated into the alt. NVDA notes capture that. The manual audit is the only way to determine WCAG conformance, and NVDA is one of the assistive technologies auditors use to do that work.
How Notes Become the Audit Report
The notes are the source material. Each row with a WCAG mapping becomes an issue entry. The actual output becomes the description. The page URL and key sequence become the reproduction steps. The severity column becomes the priority rating.
Audit reports from Accessible.org are written this way, with every issue traceable back to a specific observation. That traceability is what makes remediation efficient: the developer reads the report, sees what NVDA said, and knows what to fix.
How long should NVDA notes be per page?
Long enough to record every observation that maps to a success criterion. A simple page might produce 10 lines. A complex web app screen with custom widgets can easily produce 40 or more.
Do you need NVDA notes if you also evaluate with JAWS and VoiceOver?
Yes. Each screen reader announces differently, and a single audit should capture all three sets of observations separately. NVDA notes are not redundant with JAWS notes.
Should NVDA notes be shared with the client?
The notes themselves are working documents. The audit report is the deliverable. Clients receive the report with issues, criteria, evidence, and remediation guidance, all drawn from the notes.
What NVDA version should auditors use?
The current stable release. NVDA updates frequently, and behavior can shift between versions, so recording the version in the notes is part of the methodology.
Strong NVDA notes are what separate a credible accessibility audit from a guess. The verbatim record is the evidence, the WCAG mapping is the argument, and the report is the result.
Contact Accessible.org to request an accessibility audit quote.
