Axe-core: Ensures elements with an ARIA role that require child roles contain them

[Payne-Yan]

Steps:

1. Open https://developer.microsoft.com/en-US/fluentui#/controls/web/datepicker
2. Navigate to date picker combobox and select the picker, calendar pops up will appear, navigate on the pop, and select date.
3. Open accessibility insights for web tools and select fast pass options.
4. Verify, whether the elements with an ARIA role that require child roles contain them(#DatePicker50-label) or not.
   

In practice, this combobox pattern has much better screen reader support than the 1.1 pattern, so this should be a bug on axe-core and not on Fluent.

I want to confirm if it is the axe-core problem?

[straker]

So I dug into this. The input field as a combobox requires that it owns one either a listbox or a popup role of dialog, grid, or tree. The input field does not designate that it has a popup using aria-haspopup="dialog", so we default to expect there to be a listbox. Furthermore, even with the aria-haspopup attribute, the input field does not own the associated dialog as it does not use aria-owns (only aria-controls). So without both of those attributes the input field is correctly failing the required children role.

[smhigley]

(I'm mostly responding to @WilcoFiers' comment over here: https://github.com/microsoft/fluentui/issues/14461#issuecomment-680778152)

@WilcoFiers I definitely agree that the Fluent pattern isn't perfect :). Its issues aren't related to the aria-required-children error, though. You can see the same error on all of the APG 1.2 combobox patterns, which do have all the correct attributes set (though axe needs to be run with the combo open). @straker if you check out the ARIA 1.2 spec, or the ARIA Practices Guide's 1.2 combobox examples, you can see that the new pattern calls for aria-controls and not aria-owns on the combobox input.

Some of the specific issues with the 1.1 pattern are captured in this write-up: https://github.com/w3c/aria/wiki/Resolving-ARIA-1.1-Combobox-Issues, and some of my own testing results from last winter are in this article under the "Known Issues" heading: https://www.24a11y.com/2019/select-your-poison-part-2/ (each of those specific issues was found on a combobox using the 1.1 pattern).

I also did a bunch of support testing on the 1.2 combobox pattern back when the updated example was merged into the APG. Some of my results are in this comment (most of the issues were code bugs that are now fixed): https://github.com/w3c/aria-practices/pull/1255#pullrequestreview-316639448. Going to page @mcking65 over here, since he might have more recent testing results, or at least ones in an easier-to-consume format :)

[WilcoFiers]

@smhigley Thank you for sharing this! That's very helpful. We're looking at what we're going to do with this. Definitely sounds like we should include the ARIA 1.2 pattern, we'll need to decide what happens with existing implementations though.

[mcking65]

We don't yet have any screen reader testing in a better format yet. We will soon (next 2 or 3 months) have combobox included in aria-at testing.

I recommend that you give a warning that is advisable to replace aria-owns with aria-controls and place the combobox role on the input. Any kind of AXE response that nudges people to use the 1.2 format, which is essentially identical to the 1.0 format except that it uses owns instead of controls, would be very helpful.

[smhigley]

Thanks @mcking65! Right now, I'd just be happy if axe didn't flag the 1.2 pattern as an error 😅.

@WilcoFiers if testing results are a blocker, I could probably find time to do some and post them here. From last time, I suppose the TL;DR is that VoiceOver was the only screen reader that had issues (and even then, the 10.14 version of VO worked OK, so it might just be a 10.15 regression).

[jnurthen]

@WilcoFiers it would be awesome to get this sooner rather than later. Even though 1.2 is not final, anything that encourages the 1.1 pattern in any way at this point is not helpful.

[WilcoFiers]

Update, we're planning this for the axe-core 4.2 release, which will be out in March / April.

[WilcoFiers]

Unfortunately, we had to postpone this one, will take this up in 4.3.

[WilcoFiers]

Also, this is essentially a duplicate of #2505. Going to close this one.