Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In Forms mode JAWS incorrectly emits semantic role of list boxes #768

Open
Vladimir-Goncharov-a11y opened this issue Sep 26, 2023 · 5 comments

Comments

@Vladimir-Goncharov-a11y
Copy link

Vladimir-Goncharov-a11y commented Sep 26, 2023

Summary

In Forms mode, JAWS users use Tab to jump between items. JAWS emits the semantic role of list boxes as "list", but the role should be "list box" instead.

  1. Rename the extension of the attached file from .txt to .html, open the sample in Chrome.
    odan_397_incorrect_list_role.txt
  2. Set PC focus into the edit field.
  3. Ensure that JAWS is in Forms mode (using alt-del)
  4. Press Tab key to jump into the listbox to get the following JAWS transcript:

--- JAWS transcript ---
list
with 2 items
Apple
1 of 2
--- end of JAWS transcript ---

As you can see, the role of the element emitted as "List", not as the "list box".

Expected result

Expected JAWS transcript should inform blind users about a widget with the role "listbox" instead of static list of the list items.

--- Expected JAWS transcript ---
list box
with 2 items
Apple
1 of 2
--- end of expected JAWS transcript ---

Actual result

Insert-Control-F5 correctly shows this widget as a list box.
Navigation in Virtual PC Cursor mode correctly shows this widget as list box (using both, arrow keys and Quick Navigation keys).

But in the Forms mode JAWS shows this object as a static list of list items - different semantic role.

Additional Information

ARIA specification defines two different roles:

Thus, "list" is the section showing static content. on the page.
But "listbox" is the widget with appropriate navigation, selection and (optionally) actions.

So, if an element <ul> has a role="listbox" then it is a widget with the role "listbox", not a static page section with static list items.

Please, emit role "list box", not "list" for listboxes in Forms mode like JAWS does in Virtual mode, and in the list of form fields after Insert-F5.

JAWS version and build number

JAWS version 2024.2308.124.400
The same for JAWS 2023 August release: JAWS version 2023.2307.37.400

Operating System and version

Microsoft Windows 10 Professional Version 22H2 (OS Build 19045.3448), System Type x64

Browser and version:

Google Chrome Version 116.0.5845.188

@JAWS-test
Copy link

JAWS-test commented Sep 27, 2023

The problem goes much further:

  • not only are listboxes output as lists, but also the other way around, lists that receive focus are output as listboxes (Lists that receive the focus are output as "listbox" #334)
  • furthermore, each list or listitem of a list (ul element) that receives focus is output with a hint for arrow key operation

In both cases, the output always depends on whether the list/listbox receives the focus or a listitem/option

This results in 2 further problems:

  • different output of select element and listbox role, although they should be output in the same way.
  • different output depending on the implementation of the listbox (focus on option or listbox), although they should be output in the same way.

See: https://codepen.io/jaws-test/pen/QWzrMqK

@JAWS-test
Copy link

JAWS-test commented Sep 27, 2023

It is even worse in NVDA, where every listbox and list is output as a list. The difference is only recognisable in VPC mode by

  • listbox: Only output of the start of the list and the active option, output of number and position
  • list: Output of list start and end as well as all list items, output of number of list items.

While the problem in JAWS only occurs in forms mode, it occurs in NVDA in both forms and VPC mode.

See nvaccess/nvda#10624

@stevefaulkner
Copy link
Contributor

The test case provided is faulty. 2 issues

  1. the label is not associated with the listbox. The label for/id pattern cannot be used unless the element it references is a labelable element, it is not
  2. the listbox itself should be focusable.

A test case with these 2 issues fixed results in JAWS announcing the listbox role as expected

@Vladimir-Goncharov-a11y
Copy link
Author

The bug is still not fixed as of JAWS 2024 May's update.

Lists and list boxes are completely different semantic roles with different meaning and different usage.
Finally, JAWS must be consistent. If an element is a listbox in the VPC then it should be a listbox in Forms mode, but not listboxes exposed as lists in Forms mode - wrong semantic role emitted.
All list boxes are emitted as lists in Forms mode (the bug).
In VPC mode they emitted correctly as list boxes.

@stevefaulkner The fixes you mentioned change nothing. IT is not possible to get role "listbox" in Forms mode with any markup.
Please, use alt-del to check your current JAWS mode, also try to use Manual Forms mode switch in JAWS.
If you get "list box" it means that you are in VPC, if you get "list:, it means you are in Forms mode.
I've uploaded another file with fixed issues you've mentioned, no differences - listboxes exposed as lists in Forms mode.
odan_397_silence2.txt
rename extention to .html to open it in Chrome.
There is 1 text field which is not related to listboxes, just a place where you can switch to forms mode and press tab key. There is also 2 listboxes, which are listboxes in VPC, but lists in Forms mode - this is the bug.

If you can create a markup where JAWS emits "list box" as a semantic role in Forms mode, I would be happy to see such example. IMHO it is not possible with JAWS 2024 at all, up to and including May's update.

@stevefaulkner
Copy link
Contributor

re-opened, think its a low priority, but an issue never the less.

@stevefaulkner stevefaulkner reopened this May 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants