Lists that receive the focus are output as "listbox"

[JAWS-test]

Summary

Lists that receive the focus are output as "listbox" (like select size>1)

1. Go to https://codepen.io/jaws-test/pen/dyyYMqg
2. Tab to the lists and listitems

Expected result

• Lists are output as lists and not as "listbox".
• Output is independent of previous element
• Output is consistent for tab navigation and when reading with the arrow keys
• Output is consistent between browsers

Actual result

• Lists that receive the focus are output as "listbox" with operating instructions (arrow key navigation), switch to form mode.
• IE 11: incorrect output only if JAWS is already in forms mode (e.g. role=application or focus previously on an input field; not if previously on a button)
• Incorrect output as "listbox" only for tab navigation. Correct output as a list when reading with the arrow keys, in the quick navigation (L, C) and in the element overview (INS+Ctrl+L, INS+Ctrl+C).
• Chrome, Firefox: Output of "listbox read-only", IE 11: Output of "listbox" as operable

Additional Information

JAWS version and build number

JAWS 2019.1909.28

Operating System and version

Windows 10

Browser and version:

Chrome 76.0.3809.132 Firefox ESR 60.9.0 IE 11.1331.16299.0

[stevefaulkner]

Why are non interactive elements being made focusable? refer to Focusable elements should have interactive semantics

[JAWS-test]

There are many web applications (e.g. SAP) that are marked with role=application. Then it is important that all content receives the focus, because otherwise it is not perceptible. Personally I think the role=application is wrong, but unfortunately it concerns many pages.

https://help.sap.com/doc/saphelp_uiaddon20/2.05/en-US/3e/9c0104db864fbabc9fc786cbdf76a4/content.htm?no_cache=true:

The ARIA role=application is added to the body of each page by SAPUI5 Core to ensure that the page can be properly navigated using the keyboard. It this is not the case, the SAPUI5 JavaScript key handler code may get overridden by the screen reader and this will hinder keyboard handling.

In addition, internal page links can lead to a list receiving the focus (is used e.g. for WCAG G124.)

Another possibility would be to use JavaScript to set the focus on the list, because these are, for example, error messages whose insertion should be perceptible. Or a list is the first element in a pop-up that gets the focus so that the pop-up is perceptible and operable.

A third possibility where the problem occurs is that the lists have been marked with access keys so that they can be accessed efficiently with the keyboard.

[JAWS-test]

Note: With JAWS 18 (and with Chrome and Firefox), the output was still correct (output as a list and not as a listbox), at least as long as JAWS was not already in Forms mode through a previous element.