Combobox label / aria-input-field-name issues

[WilcoFiers]

The following (example 5 from WAI-ARIA) fails the label and the aria-input-field-name rules in axe-core:

<div aria-label="Tag" role="combobox" aria-expanded="true" aria-owns="owned_listbox" aria-haspopup="listbox">
    <input type="text" aria-autocomplete="list" aria-controls="owned_listbox" aria-activedescendant="selected_option">
</div>
<ul role="listbox" id="owned_listbox">
    <li role="option">Zebra</li>
    <li role="option" id="selected_option">Zoom</li>
</ul>

This is because the input[type=text] and the role=listbox elements don't have their own accessible name. We should do some testing to figure out exactly how this works. But I would argue that in this scenario the combobox is the only thing that's required to have an accessible name.

@schne324 I think this is an oversight in ARIA as well, which says that listbox / textbox always have to have an accessible name, even though one of their own examples shows a scenario where it doesn't. Alternatively it could be argued that they should inherit the accessible name, but in that case there's something missing in accName.

[schne324]

@WilcoFiers I agree that this is an oversight. If you look at all of the apg examples none of them have an accessible name like you said.

Do you want to raise a ticket in the aria repo?

[WilcoFiers]

Opened an issue in the ARIA group here: w3c/aria#1046

We should do some testing to figure out what solution(s) work best. My guess is axe-core shouldn't require combobox to have an accessible name, except if its also native textbox.

[aleventhal]

We have an issue in Chrome with ARIA 1.1 comboboxes that I'd like to resolve: https://bugs.chromium.org/p/chromium/issues/detail?id=850284

The spec and the official ARIA practices examples aren't aligned on what to do for the ARIA combobox. The spec says to label the combobox object, but the ARIA practices example labels the textfield. I filed an issue on ARIA practices here:
w3c/aria-practices#886

Given that the ARIA practices has been out there for so long, here are some suggestions:

• The browser could forward the combobox name to the input, if the input is nameless
• We could expect the AT to look for a parent combobox name, if it is on a nameless input. I believe NVDA does this.

[stevenyxu]

This issue is being surfaced in our internal testing since we use the APG example to label only the input and not the combobox. Can anyone on Chrome/WAI/axe give a stopgap authoring recommendation while all of this gets resolved?

Is there a harm in labelling both? As @aleventhal points out in the related bugs, labelling only the combobox per the spec results in the textbox failing to register a label in some situations. I'm happy to label both, redundant as it may seem.

[straker]

I tested this on a few AT/browser combinations and here are the results of focusing the input field:

• Voiceover/Safari on Mac - Tag, edit text
• Voiceover/Chrome on Mac - Tag, expanded, combobox
• NVDA/Firefox on PC - List, Bullet Zoom, 2 of 2
• JAWS/IE11 on PC - Listbox, Zoom

[WilcoFiers]

Given the test results, axe-core is doing the appropriate thing. Textfield and listbox need to have an accessible name, otherwise some screen readers will not announce it properly.