role combobox does not work

[JAWS-test]

Summary

Go to

• https://w3c.github.io/aria-practices/examples/combobox/grid-combo.html
• https://w3c.github.io/aria-practices/examples/combobox/combobox-autocomplete-list.html
• https://w3c.github.io/aria-practices/examples/combobox/combobox-autocomplete-none.html
• https://w3c.github.io/aria-practices/examples/combobox/combobox-autocomplete-both.html
• https://w3c.github.io/aria-practices/examples/combobox/combobox-select-only.html

with Tab key, with arrow key, check it with overview lists (INS+Ctrl+C/E)

Expected result

correct and consistent output

Actual result

see for ARIA APG 1.1 problems for combobox: #221

https://w3c.github.io/aria-practices/examples/combobox/grid-combo.html

Chrome, Firefox:

• Input hint that the list can be opened with arrow keys, but this is not possible (list only opens after text entry)
• first column is always output with selected (because of aria-selected), output should only be done if multiple selection is possible

IE11:

• no output of grid cells, instead "not in a table" is output

https://w3c.github.io/aria-practices/examples/combobox/combobox-autocomplete-list.html, https://w3c.github.io/aria-practices/examples/combobox/combobox-autocomplete-none.html, https://w3c.github.io/aria-practices/examples/combobox/combobox-autocomplete-both.html

Chrome, Firefox:

• Read with virtual cursor: First value, then role
• INS+Ctrl+C: only label, no output of value and role

IE11:

• is output as input field
• With Tab: no output of the value (only hint that the input field contains a value)

IE11, Chrome, Firefox:

• if the virtual cursor is behind the element and one navigates backwards with Shift+Tab, the button to open the list gets the focus (although it has tabindex=-1)

https://w3c.github.io/aria-practices/examples/combobox/combobox-select-only.html

IE11, Chrome, Firefox:

• no output of the value (see Select-only combobox w3c/aria-practices#1396 (comment))

IE 11:

• with Tab the focus remains on the previous link and this is also output

Firefox:

• Output as combobox edit, although no text input is possible

Additional Information

JAWS version and build number

JAWS 2020.2003.13

Operating System and version

Windows 10

Browser and version:

Current version of Chrome, Firefox ESR and IE 11

[mcking65]

@JAWS-test, When there are so many different issues/potential bugs in a single github issue, it makes it difficult to comment and track progress. You can't tell what the potential bug is from the issue title either.

I'd say that a huge portion of combobox is working pretty well, so the title of this issue is rather misleading.

Here's my input on a few of the issues.

About the hint to use arrow key to open, you noted for the grid combo that:

Input hint that the list can be opened with arrow keys, but this is not possible (list only opens after text entry)

I don't think this should be considered a JAWS bug. It is an interesting problem that might not be solveable right now. There are some comboboxes where the list is not available until some input is provided. We have an APG issue open to change this particular implementation, but that would not address the fundamental issue that there are real-world cases where the list is so large that some filter characters are required and there is no way for the screen reader to know that.

One possible resolution would be a value of aria-expanded that means collapsed but not expandable. Once characters are typed, it could change to collapsed and expandable, and when the list is open, it could be expanded. This is not a common edge case, however. So, changing the APG is probably best. I don't think this should be considered a JAWS bug.

BTW, this is the kind of thing that we work out in the aria-at project. I would be opposed to an aria-at assertion that would fail the current JAWS hint behavior for this specific example.

For the issue related to aria-selected in the grid example you wrote:

first column is always output with selected (because of aria-selected), output should only be done if multiple selection is possible

I don't think this should be a JAWS bug. I disagree with your assertion that selected should only be announced in a grid when multiple select is possible. When the drop down is a single-select list, your assertion is fine. However, in this particular implementation, selection is on the cell, and not every cell is selectable.

Admitedly, The content of this grid combo example is not as illustrastive as it could be. And, I think the APG task force needs to do more work to explore all the possibilities for how grid combos could be made. In the meantime, if JAWS were to suppress the announcement of selected in this special case, the potential for that to cause bugs in other circumstances where announcing selected is required is enormous. I think JAWS should keep announcing the selected attribute on selected grid cells.

There is one circumstance in a grid combo where screen readers MIGHT consider not announcing selected -- the row is being selected instead of single cells. But, this would have to be limited to grids that open from a combo, and I think making this special case is also risky.

Basically, this grid combo pattern is too new for screen readers to start implementing special case logic.

About the issue of value for select-only combobox you wrote:

https://w3c.github.io/aria-practices/examples/combobox/combobox-select-only.html
IE11, Chrome, Firefox:
no output of the value

This is not a JAWS bug so should not be raised here. Implementation of support for exposing the value is still work in progress for the browsers. We will have at least 2 browser implementations before ARIA 1.2 exits CR. You can see my reply to your comment in the APG PR.

[JAWS-test]

@mcking65

Thank you for your detailed answer. Some of the points can be discussed. But for me the problem is much more fundamental:

• Freedom Scientific has for years claimed to support IE 11
• IE 11 was and is the standard browser in many companies and public authorities; alternative browsers may not be used or cannot be used
• Tens of thousands of people work in this companies and public authorities, many of them blind.
• The HTML element select is by far the most unpopular element among web designers and developers. When asked "Which form control gives you the most frustration", 42% answered: The select element. All other HTML elements reach only 1-17% (see https://gwhitworth.com/blog/2019/07/form-controls-components/, Aria practice collaboration with Open UI w3c/aria-practices#1422).
• As a result, for many years now, most websites have not been using the native HTML element select but a custom element with role=combobox
• There is no version of JAWS that supported role=combobox in IE 11 - no matter whether the ARIA 1.0, 1.1, or 1.2 pattern was used. The problems were severe: Often the element was not output at all, but when role=combobox got the focus with Tab, JAWS output the name, role, and value of the previous element, and the JAWS cursor was also on the previous element.
• As a consequence, most Web pages and Web applications have been inaccessible to blind users in IE 11 with JAWS for about 10 years!
• The corresponding tickets that were posted here for Freedom Scientific were not processed at all for a very long time. In the last weeks Freedom Scientific closed all tickets related to role=combobox. Reason: There is the new ARIA 1.2 pattern. But it was never checked if the problems with this pattern still exist (which is the case with IE 11 at least).
• And concerning Firefox and Chrome: The missing output of the value for the select-only combobox is also a problem. Because currently there is no browser that supports this. This may change in the future, but the problem is that not all users have the latest version of JAWS and the latest browser. This is especially true for all professional JAWS users in companies and public authorities. Furthermore: How fast will the websites convert their ARIA 1.0 and ARIA 1.1 comboboxes?
• I.e., for the foreseeable future, most blind users using JAWS will not be able to use role combobox, which means that most Web sites will still be inaccessible