JAWS Screen Reader: A Comprehensive Guide for Accessibility Testing

JAWS (Job Access With Speech) is a screen reader developed by Freedom Scientific, a Vispero company. It is the most widely used screen reader in enterprise and government environments, with a dominant market share among professional screen reader users on Windows. For accessibility testers and developers, understanding JAWS is essential because many of your end users — particularly in corporate, financial, and public sector settings — depend on it daily.

While NVDA has grown significantly as a free alternative, JAWS remains the gold standard in many organizations due to its deep integration with enterprise applications, extensive scripting capabilities, and decades of refinement. If you are building software that must meet WCAG 2.x or Section 508 requirements, testing with JAWS is not optional — it is expected.

What Makes JAWS Different

JAWS distinguishes itself from other screen readers in several ways:

• Mature enterprise support — JAWS has been in development since 1995 and has deep support for enterprise applications including Microsoft Office, SAP, Oracle, and custom business software.
• Scripting engine — JAWS includes a full scripting language that allows power users and IT departments to customize how applications are read, making even poorly coded software more accessible.
• Braille support — JAWS has the most comprehensive refreshable braille display support of any screen reader, supporting dozens of display models and multiple braille translation tables.
• Training resources — Freedom Scientific provides extensive training materials, and most assistive technology training programs teach JAWS as the primary screen reader.
• Tandem — A built-in remote access feature that lets a sighted user and a JAWS user share a screen for troubleshooting and training.

Licensing and Cost

JAWS is commercial software with a significant price tag. Understanding the licensing model is important for planning your testing setup:

• Professional license — A single-user perpetual license costs approximately $1,000 USD. This includes one year of Software Maintenance Agreement (SMA) for updates.
• Annual SMA renewal — After the first year, maintaining access to updates costs around $340 USD per year. Without an active SMA, JAWS continues to work but does not receive updates.
• Home license — A lower-cost option (around $90/year) intended for personal, non-commercial use. Not suitable for professional testing.
• Site licenses — Volume licensing is available for organizations deploying JAWS across many workstations.
• 40-minute demo mode — This is the key feature for developers and testers. JAWS can be downloaded and used for free in 40-minute sessions. After 40 minutes, you must restart the computer (not just JAWS) to get another 40-minute window. This is fully functional and perfectly adequate for accessibility testing.

For accessibility testing purposes, the 40-minute demo mode is often sufficient. Plan your testing sessions to fit within this window. Many teams keep a dedicated testing machine that they restart between sessions.

The Virtual Cursor

The virtual cursor is the most important concept to understand when using JAWS for web testing. When JAWS loads a web page, it creates a virtual representation of the page — the Virtual PC Cursor buffer. This is conceptually similar to NVDA's browse mode.

In virtual cursor mode, JAWS intercepts all keyboard input and uses it for navigation commands rather than passing keystrokes to the browser. You can move through the page element by element, jump between headings, navigate by landmarks, and more — all without a mouse.

Key characteristics of the virtual cursor:

• Arrow keys move through the page content linearly, one element at a time.
• Quick navigation keys (single letters like H, T, F) jump between specific element types.
• The virtual cursor position is independent of the browser's focus — you can be reading one part of the page while the browser focus is elsewhere.
• JAWS announces element types, states, and properties as you navigate (e.g., "heading level 2", "link visited", "checkbox not checked").

The JAWS Key

Most JAWS commands use a modifier key called the JAWS key. By default, this is the Insert key on the keyboard. On laptops without a dedicated Insert key, Caps Lock can be configured as an alternative JAWS key.

Throughout this guide, Insert refers to the JAWS key. If you have remapped it to Caps Lock, substitute accordingly.

Essential Navigation Shortcuts

These are the keyboard shortcuts you will use most frequently when testing web pages with JAWS. All of these work in virtual cursor mode.

Heading Navigation

• H — Move to the next heading (any level).
• Shift+H — Move to the previous heading.
• 1 through 6 — Move to the next heading of that specific level (e.g., 2 jumps to the next <h2>).
• Shift+1 through Shift+6 — Move to the previous heading of that specific level.

Heading navigation is the primary way screen reader users scan and understand page structure. When testing, verify that your heading hierarchy is logical and that all major content sections have appropriate headings.

Table Navigation

• T — Move to the next table.
• Shift+T — Move to the previous table.
• Ctrl+Alt+Right Arrow — Move to the next cell in the current row.
• Ctrl+Alt+Left Arrow — Move to the previous cell in the current row.
• Ctrl+Alt+Down Arrow — Move to the cell below in the current column.
• Ctrl+Alt+Up Arrow — Move to the cell above in the current column.

When navigating table cells, JAWS announces the column and row headers automatically if they are properly marked up with <th> elements and scope attributes. This is a critical test: if JAWS does not announce headers when moving between cells, your table markup needs fixing.

Form Field Navigation

• F — Move to the next form field (input, select, textarea, button).
• Shift+F — Move to the previous form field.
• B — Move to the next button.
• Shift+B — Move to the previous button.
• C — Move to the next combo box (select element).
• X — Move to the next checkbox.
• A — Move to the next radio button.

Landmark and Region Navigation

• R — Move to the next ARIA landmark or HTML5 sectioning element (nav, main, aside, footer, etc.).
• Shift+R — Move to the previous landmark.
• Q — Move to the next blockquote.
• Shift+Q — Move to the previous blockquote.

Landmark navigation is how experienced screen reader users quickly orient themselves on a page. Test that your page has a <main> landmark, a <nav> for navigation, and that landmarks are labeled when there are multiples of the same type.

Other Navigation Keys

• K — Move to the next link (visited or unvisited).
• U — Move to the next unvisited link.
• V — Move to the next visited link.
• I — Move to the next list item.
• L — Move to the next list.
• G — Move to the next graphic (image).
• D — Move to the next ARIA landmark region (same as R in most configurations).
• S — Move to the next separator (<hr>).

Element Lists

JAWS provides dialog-based lists of elements that give you a comprehensive overview of the page structure. These are invaluable for testing:

• Insert+F5 — Open the form fields list. Shows all form controls on the page with their labels (or lack thereof). Quickly reveals unlabeled fields.
• Insert+F6 — Open the heading list. Displays all headings with their levels in a tree view. Instantly reveals heading hierarchy problems like skipped levels or missing headings.
• Insert+F7 — Open the link list. Shows all links on the page. Reveals ambiguous link text like "click here" or "read more" that lack context.
• Insert+F3 — Open the virtual viewer (all elements list). This is the most powerful diagnostic tool — it shows every element JAWS has identified on the page, organized by type. You can filter by headings, landmarks, form fields, links, graphics, tables, and more.
• Insert+F9 — Open the frame list. Shows all frames and iframes on the page.

Reading Commands

• Insert+Down Arrow — Say All. Reads from the current position to the end of the page continuously.
• Insert+Up Arrow — Read current line.
• Insert+Numpad 5 — Read current word.
• Numpad 5 — Read current character.
• Insert+T — Read the page title (the content of the <title> element).
• Insert+Tab — Read the currently focused element with all its attributes and states.
• Ctrl — Stop speech immediately.
• Insert+Spacebar — Pause/resume speech.

Utility Commands

• Insert+F2 — Open the JAWS Manager list. This is the central hub that gives quick access to all JAWS utilities, settings, and managers.
• Insert+F1 — Screen-sensitive help. Provides context-aware information about what JAWS is currently doing and available commands.
• Insert+F1 (pressed twice quickly) — Opens JAWS keyboard help mode, where pressing any key combination tells you what it does instead of executing it.
• Insert+V — JAWS verbosity quick settings. Toggle what information JAWS announces (graphics, links, tables, etc.).
• Enter — Activate a link or button. Also switches to forms mode when pressed on a form field.

Forms Mode vs Virtual Cursor Mode

Understanding the distinction between forms mode and virtual cursor mode is critical for both testing and understanding how JAWS users interact with your web content.

Virtual cursor mode (also called browse mode) is the default when a web page loads. In this mode, JAWS intercepts keyboard input for navigation. You cannot type into form fields in this mode.

Forms mode (also called application mode) passes keyboard input directly to the browser, allowing interaction with form controls. When in forms mode, quick navigation keys like H and T are not available — pressing H would type the letter "h" into a field instead.

JAWS can switch between these modes in two ways:

• Auto Forms Mode (default) — JAWS automatically enters forms mode when you navigate to a form field using Tab or when you press Enter on a form field in virtual cursor mode. It automatically returns to virtual cursor mode when you Tab past the last form field.
• Manual Forms Mode — You explicitly press Enter to enter forms mode on a form field and press Numpad Plus (or Escape) to exit back to virtual cursor mode.

Common testing issues related to forms mode:

• Custom widgets that trap focus and prevent users from exiting forms mode.
• ARIA roles that force forms mode when it is not appropriate (e.g., role="application" used incorrectly).
• Dynamic content that appears after a form interaction but is not announced because JAWS is in forms mode and the virtual buffer has not refreshed.
• Custom controls that do not work in forms mode because they rely on keyboard handlers that JAWS intercepts in virtual cursor mode.

Configuring JAWS for Web Testing

Before you begin testing, adjust these JAWS settings to get the most accurate and useful results:

• Verbosity level — Set to "Advanced" or "All" during testing. This ensures JAWS announces all ARIA attributes, roles, and states. Go to Settings Center (Insert+F2, then select Settings Center) and navigate to Web / HTML / PDF > Reading > Verbosity Level.
• Virtual cursor auto forms mode — Keep this enabled (it is the default). This mirrors how most JAWS users interact with forms in real usage.
• Graphics verbosity — Set to "All" so JAWS announces all images, including those with empty or missing alt text. This helps you catch missing alt attributes.
• Speech rate — Slow the speech rate to a comfortable speed for testing. Press Alt+Ctrl+Page Up to increase speed or Alt+Ctrl+Page Down to decrease it.
• Speech and sounds scheme — Use the "Classic" scheme for testing, as it provides distinct audio cues for different element types.
• Braille viewer — If you do not have a physical braille display, enable the braille viewer (Insert+F2 > Braille Viewer) to see the braille output on screen. This is useful for checking that information conveyed visually is also available in braille output.

PlaceMarkers and Custom Labels

JAWS offers two features for persistent customization of web pages that are useful for repetitive testing:

PlaceMarkers allow you to mark specific locations on a web page and return to them quickly. This is useful when you are repeatedly testing the same page regions:

• Ctrl+Shift+K — Set a temporary PlaceMarker at the current position.
• K — Move to the next PlaceMarker.
• Shift+K — Move to the previous PlaceMarker.
• PlaceMarkers persist across JAWS sessions for the same URL, making them valuable for regression testing.

Custom Labels let you assign descriptive labels to elements that are unlabeled or poorly labeled. While this is primarily a user-facing feature, it is valuable during testing to note which elements need fixing:

• Insert+Ctrl+Tab — Assign a custom label to the current element.
• Custom labels override whatever JAWS would normally announce for that element.
• These labels are stored per-domain and persist across sessions.

Browser Compatibility

JAWS behaves differently across browsers, and these differences matter for testing. Here is what you need to know:

Google Chrome — Currently the most popular browser among JAWS users. JAWS communicates with Chrome via the IAccessible2 (IA2) accessibility API. Chrome generally provides good ARIA support, and most modern web applications are tested primarily in Chrome with JAWS. Use Chrome as your primary JAWS testing browser.

Microsoft Edge — Since Edge is now Chromium-based, JAWS behavior in Edge is very similar to Chrome. Some differences exist in how Edge exposes certain native HTML elements through the UIA (UI Automation) accessibility API. Edge is a good secondary testing browser.

Mozilla Firefox — Firefox uses its own accessibility API implementation and can sometimes expose ARIA attributes differently than Chrome. JAWS + Firefox historically had strong standards compliance. However, some complex ARIA patterns may behave differently. Test in Firefox when you encounter unexpected behavior in Chrome.

Internet Explorer 11 — While IE11 is end-of-life, some enterprise environments still require it. JAWS + IE11 uses MSAA (Microsoft Active Accessibility), the oldest and most limited accessibility API. Many modern ARIA roles and attributes are poorly supported or unsupported in this combination. Only test with IE11 if your users specifically require it.

As a general rule, test with the browser your users actually use. When in doubt, Chrome is the safest default for JAWS testing.

JAWS Scripting and Customization

One of the most powerful features of JAWS is its scripting engine. JAWS scripts are written in a proprietary language and can fundamentally change how JAWS interacts with an application.

For web accessibility testing, you do not need to write JAWS scripts. However, understanding that they exist is important:

• Application scripts — Custom scripts can be written for specific applications or websites to improve accessibility. Organizations sometimes write scripts as a workaround for inaccessible software.
• Script files — Scripts are stored as .jss (source) and .jsb (compiled) files in the JAWS settings directory.
• Script Manager — Accessed via Insert+F2 > Script Manager, this is where scripts are created and edited.
• Shared scripts — JAWS users can share scripts, and Freedom Scientific maintains a repository of scripts for popular applications.

If your application requires a JAWS script to be usable, that is a strong indicator that the underlying accessibility needs improvement. The goal should always be to make the application work with JAWS out of the box.

JAWS vs NVDA: Key Differences for Developers

Both JAWS and NVDA are Windows screen readers that provide similar core functionality, but there are important differences that affect how you test and what issues you find:

• Virtual buffer implementation — JAWS and NVDA build their virtual buffers differently. JAWS uses its own proprietary rendering, while NVDA uses the browser's accessibility tree more directly. This can lead to different behaviors with the same HTML.
• ARIA support — JAWS sometimes has more mature support for complex ARIA patterns (like aria-owns, aria-flowto) because Freedom Scientific works closely with enterprise clients who need these features. NVDA may lag slightly on newer or edge-case ARIA attributes.
• Forms mode behavior — JAWS auto forms mode and NVDA focus mode behave similarly but not identically. The threshold for when automatic mode switching occurs can differ, particularly with custom ARIA widgets.
• Live region handling — aria-live regions can be announced differently by JAWS and NVDA. JAWS tends to be more conservative about announcing repeated live region updates, while NVDA generally announces all updates.
• Table reading — JAWS typically announces more table context information (row/column counts, current position) than NVDA by default.
• Verbosity and settings — JAWS has significantly more granular verbosity settings than NVDA, allowing fine-tuned control over what is announced.
• Price and availability — NVDA is free and open source, making it easier to deploy across a team. JAWS requires per-seat licensing or use of the 40-minute demo mode.

Testing Workflow with JAWS

A structured approach to JAWS testing ensures consistent, thorough results. Follow this workflow for each page or component you test:

• Step 1: Page load announcement — When the page loads, listen to what JAWS announces. It should read the page title and begin reading the page content. Verify the <title> is descriptive and unique.
• Step 2: Heading structure — Press Insert+F6 to open the heading list. Verify that headings form a logical hierarchy without skipped levels, and that all major content sections have headings.
• Step 3: Landmark structure — Press R repeatedly to cycle through landmarks. Verify that the page has appropriate landmarks (main, nav, banner, contentinfo) and that duplicate landmark types have unique labels.
• Step 4: Link review — Press Insert+F7 to open the link list. Check for ambiguous link text. Every link should make sense out of context.
• Step 5: Image review — Press G to navigate through images. Verify that informative images have meaningful alt text, decorative images are hidden from JAWS, and complex images have adequate descriptions.
• Step 6: Form testing — Press Insert+F5 to review form fields. Verify all fields have associated labels. Then interact with each form field: enter data, select options, submit the form, and verify error handling is announced.
• Step 7: Interactive components — Test all interactive elements (menus, tabs, dialogs, accordions) with the keyboard. Verify ARIA roles and states are announced correctly, focus management works properly, and dynamic content changes are communicated.
• Step 8: Dynamic content — Trigger any dynamic updates (AJAX loading, live notifications, content changes) and verify JAWS announces them appropriately via live regions or focus management.

Enterprise Accessibility Testing with JAWS

In enterprise environments, JAWS testing has additional considerations beyond basic web testing:

• Version matrix — Enterprises often standardize on specific JAWS versions. You may need to test with JAWS 2023, 2024, and 2025 to cover your user base. Behavior can differ significantly between major versions.
• Locked-down configurations — Enterprise JAWS installations may have custom settings profiles, scripts, or restricted configurations. Test with both default and enterprise-configured JAWS when possible.
• Integration with enterprise tools — Test how your application works with JAWS when used alongside enterprise staples like Microsoft Teams, Outlook, and SharePoint. Ensure task-switching between these applications and your web application does not cause JAWS to lose context.
• Performance — Large enterprise applications with complex DOM structures can cause JAWS to slow down significantly as it builds and updates its virtual buffer. Test with realistic data volumes.
• Single sign-on flows — SSO redirects and multi-step authentication flows must maintain JAWS usability throughout. Focus management after redirects is a common failure point.

Common Issues Found with JAWS Testing

These are the most frequent accessibility issues that JAWS testing reveals, organized by category:

Missing or inadequate labels:

• Form fields without associated <label> elements or aria-label / aria-labelledby attributes. JAWS announces these as "edit" or "combo box" with no description.
• Icon buttons with no accessible name. JAWS announces "button" with no indication of what the button does.
• Images with missing alt attributes. JAWS falls back to reading the filename, which is usually unhelpful (e.g., "img_3847.jpg").

Focus management failures:

• Dialogs that open without moving focus into them. JAWS users continue reading the underlying page and may not realize a dialog has appeared.
• Content that appears dynamically (e.g., error messages, search results) without an aria-live region to announce the change.
• Focus traps in custom widgets where Escape does not close the widget and return focus to the trigger.
• Focus not returning to the trigger element when a dialog or popover closes.

Incorrect ARIA usage:

• role="application" used on a container, which disables virtual cursor navigation for that entire region. This should be used extremely sparingly.
• Missing aria-expanded on disclosure widgets, so JAWS users cannot tell if a section is open or closed.
• aria-hidden="true" applied to visible, interactive content, making it completely invisible to JAWS.
• Custom widgets using incorrect ARIA roles or missing required ARIA attributes (e.g., a tablist without aria-selected).

Reading order and structure:

• Visual layout that does not match DOM order, causing JAWS to read content in an illogical sequence.
• CSS-only visual headings (large bold text) that are not actual heading elements. JAWS users cannot navigate to them with H.
• Content injected into the page at an unexpected DOM position, causing it to be read at the wrong point in the content flow.

When to Test with JAWS vs NVDA vs VoiceOver

Each screen reader has its place in a comprehensive testing strategy. Here is when to use each:

Use JAWS when:

• Your primary audience is in enterprise, government, or regulated industries where JAWS has the highest market share.
• Testing complex ARIA widgets, especially those involving aria-owns, aria-flowto, or advanced live regions.
• Testing applications that integrate with Microsoft Office or other desktop enterprise software.
• You need to verify behavior with a screen reader that has extensive scripting customization capabilities.
• Your organization has contractual obligations that specifically require JAWS testing.

Use NVDA when:

• You need a free, always-available testing tool for daily development testing.
• Testing general web content where NVDA's behavior closely mirrors the majority of screen reader users on Windows.
• Running automated testing workflows, as NVDA is easier to integrate into CI/CD pipelines.
• You want to test with a screen reader that follows web standards more strictly, as NVDA tends to be less forgiving of improper markup.

Use VoiceOver when:

• Testing for macOS and iOS users. VoiceOver is the only screen reader on Apple platforms.
• Testing mobile web accessibility on iPhone and iPad, where VoiceOver + Safari is the dominant screen reader combination.
• Verifying that your site works on WebKit-based browsers, as VoiceOver + Safari can expose different issues than Windows screen readers + Chrome.

The ideal testing combination:

• For most web projects, test with JAWS + Chrome and NVDA + Firefox on Windows, plus VoiceOver + Safari on macOS.
• If resources are limited, NVDA + Chrome is the single most representative combination for desktop web testing.
• For enterprise applications, JAWS + Chrome should be your primary combination, supplemented by NVDA testing.
• For mobile-first or responsive sites, add VoiceOver + Safari on iOS to your testing matrix.

No single screen reader catches every issue. Differences in how JAWS, NVDA, and VoiceOver interpret ARIA attributes, handle focus management, and build their virtual representations of a page mean that each one can reveal unique problems. A robust accessibility testing strategy always includes multiple screen readers.