Permit ARIA 1.2 combobox (without textbox child)

Expectation: A compliant ARIA 1.2 (draft) combobox should not raise axe violations.

Actual: ARIA 1.2 combobox raises aria-required-children violation. Demo: https://w3c.github.io/aria-practices/examples/combobox/combobox-select-only.html. Currently raises 1 violation, aria-required-children.

Motivation: ARIA 1.2 is redefining combobox (draft spec) to no longer require a textbox child because of various issues with the 1.1 combobox. Aside from resolving long-standing labelling and SR support issues, this is particularly useful for web applications that want to emulate a native select or provide a rich selection widget (e.g. a form select with a popup that includes multiselection, options filter, select all/none). The current common practice is to use a popup button as the trigger rather than a combobox, but this is problematic in a form setting because button has problems with aria-required (prohibited by spec, flagged by axe, though supported in practice) and aria-invalid (permitted by spec, but not supported in practice). I’ve tested the new pattern with combobox trigger on JAWS, NVDA, ChromeVox on ChromeOS, VoiceOver, iOS VoiceOver, and Android TalkBack, and they all correctly announce current value, requiredness, and invalidness. In light of the apparent widespread support and that it’s in a draft spec, it would be nice to permit it in axe. A couple of projects I’m involved with including Angular Material have already cut over to the new pattern because of the clear a11y wins, and we’re currently suppressing (in tooling) and manually ignoring (when using axe extension) the axe violation.

axe-core version: 3.5.5
axe-webdriver, extension or other integration version: 4.5.3

Browser and Assistive Technology versions

For Tooling issues:
- Platform:  Tested on Chrome 84 OS X, reproducible running axe-core as a standalone library on node v10.

[smhigley]

@straker / @WilcoFiers I did some testing, and I think axe wouldn’t require any special casing or version detection to make this work well. I created a few combobox variations of the 1.1 and 1.2 patterns that mix and match having a child input and switching aria-controls for aria-owns: https://codepen.io/smhigley/full/zYoEMWP. (I left off 1.0, because if you switch aria-owns for aria-controls, it just becomes 1.2).

As you can see, there is no practical support problem with removing the child input for the 1.1 pattern, or leaving out aria-owns in favor of aria-controls in the 1.1 pattern. So, for all patterns, the following are true:

• No pattern requires a child input
• All patterns require one of aria-owns or aria-controls, but it doesn’t matter which one

It seems like if axe removed the aria-required-children for combobox entirely, and added a check for either aria-owns or aria-controls regardless of pattern version, that should cover all cases.

This makes sense from a technical perspective: the thing doing the heavy lifting is aria-activedescendant, and it doesn’t really matter if the combo/listbox association is done via aria-owns or aria-controls. And a 1.1 pattern without a child input is just a select-only 1.2 pattern with aria-owns 😃

[AutoSponge]

For another example, here’s a demo using angular material that gets flagged in axe: https://angular-ph3vth-e514sq.stackblitz.io/. In this example, the listbox is dynamically created (axe complains it doesn’t have the right child) then continues to flag in the open state. I assume it’s because the listbox isn’t the first child (nested in a div). The listbox is directly linked with aria-controls.

If this example is accessible, then the rule aria-required-children is a false positive.