Virtual PC Cursor becomes lost with programmatic focus shifts to list elements

[Epic-Third-Party-Bug-Reporting]

Summary

If a page programmatically assigns focus to a list element or element within a list element, the JAWS Virtual PC Cursor can become unresponsive.

Example:

1. Construct an unordered list with several elements, and mark at least one element with tabindex="-1" to allow it to receive programmatic focus.
2. Optionally place traditionally focusable elements, such as <button> elements, inside the list elements.
3. Construct a button or similar method outside of the list, and attach an event listener which can call .focus() on the list element or focusable element within the list.
4. Observe that the list can be navigated with Virtual PC Cursor at first, but after triggering the .focus() call, it no longer can.

Expected result

• Virtual PC Cursor should continue to function, i.e. the arrow keys should continue to navigate through the list and the rest of the page.
• Unless focus is placed on a form field within the list element, JAWS should not enter Forms Mode.

Actual result

• Virtual PC Cursor becomes unresponsive.
• The audio cue that JAWS has entered Forms Mode is heard.
• Toggling the Virtual PC Cursor on and off (Ins+Z) does nothing.
• User must either press Esc to exit forms mode or Tab to leave the current list element before they can begin to navigate with Virtual PC Cursor again.

Example

https://jsfiddle.net/1gy46oz8/9/ This fiddle includes a simple 5-element list where each element contains a button. Buttons to focus on the 3rd list element and on the button within are both provided. Additionally, a button to goggle the list-style CSS property is provided to demonstrate that the issue is not specific to lists with list-style: none.

Note: If focusing on the list element, the user must press Tab twice to restore Virtual PC Cursor navigation - a single Tab moves focus from the list element to the button within and Virtual PC Cursor navigation remains broken. Successfully tabbing to the button within the following list element restores Virtual PC Cursor navigation.

Additional Information

JAWS seems to lag significantly after the user attempts to use Virtual PC Cursor navigation in this state. JAWS response to any inputs becomes noticeably slower after the user attempts to use Virtual PC Cursor navigation following the .focus() call.

This lag is not present if the user immediately uses the Tab key after the .focus() call and successfully avoids the issue. It is specifically the attempt to use Virtual PC Cursor navigation in this state that appears to cause the lag.

JAWS version and build number

Tested on each of the following JAWS builds:

1. 2022.2206.9
2. 2022.2211.7
3. 2023.2210.29

Operating System and version

Windows 10 Enterprise 10.0.19044 Build 19044

Browser and version:

Chrome 108.0.5359.125

[JAWS-test]

I can confirm the bug. It occurs not only in Chrome, but also in Firefox and Edge

The bug does not occur with NVDA.

I have also noticed the bug annoyingly for years.

The cause of the bug is the following behavior of JAWS:

• When a list item gets focus or the list item is focusable (tabindex attribute), JAWS thinks it is not a list but a select list (like <select size=x> + <option> where x>1 or like role=listbox + role=option).
• In select lists, it is correct that JAWS disables the virtual cursor and switches to form mode because they are operated with the arrow keys.

This is a JAWS bug because the focusable list items are correctly submitted by the browser to the Accessiblity API as a list and not a select list