JAWS screen reader testing can be used when auditing a digital asset. Sometimes this is in place of NVDA or another screen reader or it can be in addition to. JAWS testing is conducted in a Windows environment.
With JAWS testing, we’re looking to see if JAWS is announcing elements correctly and whether the page can be navigated and operated as expected by someone relying on the screen reader.
| Element | What to Capture |
|---|---|
| Environment | JAWS version, Windows version, browser and version |
| Location | URL, page title, and the specific component or region |
| Action | Exact JAWS command or keystroke used |
| Output | What JAWS actually announced, verbatim where possible |
| Expected | What a conforming experience would have announced |
| WCAG Mapping | Success criterion the observation falls under |
Setting Up the Environment Before You Start
Document the JAWS version, Windows version, and browser pairings used during evaluation. JAWS pairs most reliably with Chrome and Firefox on current Windows builds. If audits cover more than one browser, note the pairing for each session separately.
Confirm verbosity is set to a level that surfaces semantic detail. Many auditors keep punctuation at most and verbosity at intermediate during evaluation so role, state, and label announcements come through clearly.
What Should Each Issue Contain?
A useful identified accessibility issue is short, specific, and reproducible. It tells a developer exactly where to go, what to do, and what they should hear once the issue is fixed.
Capture the URL, the component, the keystroke or command used, and the announcement verbatim. Quote JAWS output the way it speaks it, including pauses and missing words. If JAWS said nothing, write “silent” rather than leaving the field blank.
Pair the observation with the relevant WCAG 2.1 AA or WCAG 2.2 AA success criterion. A button with no accessible name is a 4.1.2 Name, Role, Value issue. A modal that traps focus incorrectly maps to 2.1.2 No Keyboard Trap. The mapping is what turns an observation into an audit finding.
And, of course, include JAWS as the screen reader that produced the issue along with the other environments.
Key JAWS Commands Worth Documenting
Auditors rely on a small set of commands repeatedly. Documenting the command alongside the expected result removes ambiguity during evaluation.
Tab and Shift+Tab: moves through interactive elements and reveals focus order issues.
H and Shift+H: navigates by heading and exposes heading structure problems.
R: jumps between landmarks and regions.
F: moves through form fields.
Insert+F7: opens the links list, useful for evaluating link text quality.
Insert+F6: opens the headings list for structural review.
Insert+F5: opens the form fields list.
Down Arrow: reads next line in browse mode and surfaces reading order issues.
When a command produces something unexpected, the corresponding note should describe the command, the page state, and the announcement together. That triplet is what makes the issue reproducible during audit work.
Common Issues to Watch For
Certain patterns appear repeatedly during JAWS evaluation. Knowing them in advance speeds up the audit and sharpens the notes.
Unlabeled buttons and icon-only controls are the most frequent. JAWS will often announce “button” with no name, or read raw class names when an aria-label is missing. Custom dropdowns and comboboxes built without proper ARIA roles often announce as a generic group rather than a combobox with expanded state.
Modal dialogs are another recurring source of issues. Focus may not move to the dialog on open, the dialog may not be announced as a dialog, and Escape may not close it. Each of these gets its own note.
Reading order in browse mode often diverges from visual order when CSS positioning is used heavily. Notes should capture the actual sequence JAWS reads alongside the visual layout for comparison.
How Do You Translate Issues Into an Audit Report?
Notes are the reference layer. The audit report is the structured output. Each pattern documented in the notes becomes a check during evaluation, and each failure observed becomes a finding with a description, the WCAG criterion, the location, severity, and a recommended fix.
The audit identifies the issue, references the actual JAWS output as evidence, and gives the development team enough detail to reproduce and remediate. Scans cannot capture screen reader behavior.
Accessible.org audits include screen reader evaluation across JAWS, NVDA, and VoiceOver depending on scope. Reference notes for each screen reader inform the evaluation so findings are grounded in expected behavior rather than assumed behavior.
Tips for Better Reports
Use a consistent structure across notes. A spreadsheet or a structured document with fixed columns prevents drift and makes the notes easier to scan during audits.
Group entries by component type or by WCAG criterion. Buttons, links, headings, forms, and modals each have distinct expected behaviors in JAWS, and grouping makes the right reference easy to find when a control comes up.
Record what correct behavior sounds like, not only what failure sounds like. Confirming that a properly built heading structure or form label reads as expected is part of the conformance picture and sharpens recognition of deviations.
How extensive should JAWS testing notes be?
Length depends on coverage. Notes that address only basic navigation and headings stay short. Notes that cover forms, modals, custom widgets, ARIA live regions, and reading order grow substantially. Focus on completeness across component types and WCAG criteria, not word count.
Should audit reports include screenshots?
Yes, when a pattern involves visual focus indicators, layout, or where a control sits on the page. A screenshot with the focused element highlighted clarifies the reference for anyone reviewing audit findings later.
Does JAWS testing replace NVDA or VoiceOver evaluation?
No. JAWS, NVDA, and VoiceOver each behave differently. An audit that covers desktop and mobile environments needs to stateassistive technologies used for the audit.
Can AI assist with organizing JAWS testing notes?
AI can help structure and cluster issues by WCAG criterion or by component, which speeds up the move from documented patterns to audit findings. Accessible.org Labs is actively researching how AI can support auditing and remediation workflows without replacing human evaluation.
Disciplined notes are the difference between a screen reader session that sharpens an audit and one that runs on guesswork. The auditor who maintains clear reference material delivers a stronger report after every evaluation.
Contact Accessible.org to discuss a manual accessibility audit that includes JAWS evaluation.
