Job Access with Speech (JAWS) Compatibility Issues

Summary

This article describes two known Job Access With Speech (JAWS) screen reader limitations on Windows that affect accessibility when using Abridge. In both cases, the affected content meets Web Content Accessibility Guidelines (WCAG) Success Criterion 4.1.2 (Name, Role, Value) in its code and in the browser's accessibility tree. The behavior comes from how JAWS interacts with or presents the content, not from Abridge site code.

Each limitation below includes the affected content, technical details, conformance information, and a testing matrix. Workarounds are provided for the first limitation.

Known limitation 1: typed text in multi-line text fields is not announced by JAWS in Chromium-based browsers

Affected content

The “Ask Abridge AI” field on Home page and the “Patient Visit Summary” field on Post Record page are native <textarea> elements.

When a JAWS user types in these fields in Chromium based browsers (such as Google Chrome or Microsoft Edge) on Windows, the characters and words entered are not announced. JAWS announces the field's name followed by "Edit, Contains text, Type in text". This is the standard JAWS announcement for any multi-line edit field using a Chromium based browser, and JAWS does not read a textarea's existing contents on focus. 

Typed text is announced as expected with JAWS in Firefox, NVDA in Chrome and NVDA in Firefox.

Technical details

Each field is a native <textarea> with a programmatically associated label. Chromium exposes each field in its accessibility tree as a multi-line, editable text box with an accessible name, the correct role, and a value that updates as text is typed. Because the name, role, and value reach the platform accessibility API correctly, the failure occurs in the interaction between JAWS and Chromium-based browsers when text is entered. No site code is involved, and the behavior is only reproduced with the JAWS and Chromium combination.

Conformance

The fields meet WCAG 2.2 Success Criterion 4.1.2 (Name, Role, Value) at the code and accessibility-tree level. The limitation arises from a gap in assistive technology support in one browser and screen reader combination, which is outside the site's control.

Workarounds for users

• In JAWS, review the field's contents with Insert + Up Arrow (current line), Insert + Down Arrow (Say All), or the arrow keys.
• Press Insert + F5 to open the JAWS form fields list and read the field's value.
•  Use JAWS with Firefox, or NVDA with Chrome or Firefox.

Testing Matrix

We tested four combinations of screen reader and browser, using the same fields and the same steps for each:

Known limitation 2: JAWS does not distinguish radio menu items from regular menu items

When using JAWS to navigate the “Select microphone for dictation” menu on the Home page, JAWS announces the radio options and the regular option in the menu in the same way, so it may not be clear which items are mutually exclusive choices. The menu is built according to the WAI-ARIA specification, and other screen readers announce it differently. 

Affected Content

Opening the menu button displays a list with several items: two or more options that work as a single-choice selection ("Microphone" and "Use Abridge App") and one separate action ("Manual punctuation").

When users move through the menu with JAWS in Chrome on Windows, JAWS announces all three items with the same generic role ("menu"), without announcing that two of them are radio options. JAWS also announces the position of each item within the whole menu, for example "1 of 3" and "2 of 3" for the two radio options. Because the radio role is not announced, this count can sound as if there were three radio options, when only two are radio options and the third is a different type of item.

With NVDA in Chrome, the same menu is announced with the role "radio menu item" for the two options, and the third item is announced as a regular menu item.

The count of three items is correct: the menu contains three items in total, and the position numbers reflect that. The radio options are also placed inside a group within the menu, which is the structure that WAI-ARIA specifications and the MDN documentation reference this type of menu. This is not an error within the code. 

Conformance

The menu meets WCAG 2.1 Success Criterion 4.1.2 (Name, Role, Value) in its code and in the browser's accessibility tree. It also follows the ARIA authoring guidance for the menu, group, menuitemradio, and menuitem roles. The limitation comes from how one screen reader presents these roles, which is outside our control.

Technical details

The menu uses the following structure:

• A container with role="menu" that holds all items.
• Inside it, a container with role="group" holding two or more elements with role="menuitemradio". Each one exposes its selected state with aria-checked.
• One additional element with role="menuitem", placed in the same menu but outside the group.

The WAI-ARIA specification requires elements with role="menuitemradio" to be contained in or owned by an element with role="menu", role="menubar", or role="group". 

We confirmed in the browser's accessibility tree that each radio item is exposed with its radio menu item role, its name, and its checked state, and that the regular item is exposed as a menu item.

Because the roles, names, states, and grouping reach the Windows accessibility interfaces correctly, the difference in what you hear comes from how JAWS presents these roles: 

• JAWS does not separate the radio menu item role from the regular menu item role when it speaks them.

Testing Matrix

We tested the same menu with the same steps in each combination: