WCAG 1.3.1: Ensures elements with an ARIA role that require child roles contain them (#DatePicker50-label).

[Payne-Yan]

Environment Information

• Package version(s): 7.115.1
• Browser and OS versions: Chrome Version 84.0.4147.105 (Official Build) (64-bit)

Describe the issue:

Ensures elements with an ARIA role that require child roles contain them

Element path
#DatePicker178-label

Snippet

How to fix
Fix the following
Required ARIA child role not present: listbox

Actual behavior:

elements with an ARIA role that requires child roles do not contain them (#DatePicker50-label).

Expected behavior:

ensures elements with an ARIA role that require child roles contain them (#DatePicker50-label).

Documentation describing expected behavior

[Payne-Yan]

Repro-Image

[paulgildea]

@smhigley FYI

[khmakoto]

Hi @Payne-Yan, I've tried reproducing this in our website unsuccessfully but I see you are a few versions behind. Could you try with our latest version and reply back? Thanks!

[Payne-Yan]

@khmakoto Repro steps

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

[khmakoto]

@Payne-Yan I've gone through the process once again and I just can't seem to repro this behavior as much as I try. Hence I'll be resolving this as Resolution: Can't repro. Thanks and let us know if there is anything else I can do to help!

[Payne-Yan]

@khmakoto According to my steps to reproduce, it can be reproduced.

[Payne-Yan]

@khmakoto More importantly, it needs to pop up the calendar and then open accessibility insights for the web tools to reproduce this scene.

[smhigley]

@Payne-Yan it looks like this is because axe-core hasn't updated to the ARIA 1.2 combobox pattern, where the combobox role is on the input and associated with the listbox/grid/etc through aria-controls. You can see the same failure if you run Accessibility Insights on the aria-practices combobox page with the combobox expanded: https://w3c.github.io/aria-practices/examples/combobox/combobox-autocomplete-list.html

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.

[khmakoto]

Thanks for responding here @smhigley!

@Payne-Yan given @smhigley's response I'm going to go ahead and resolve this as Resolution: External. Let us know if there is anything else we can do to help!

[khmakoto]

Yes, that seems to be the case.

[smhigley]

Yes, though it's slightly complicated by ARIA 1.2 still being a Working Draft and not a full recommendation. I still think axe-core should remove that required children combobox rule, though. The justifications would be:

• Even though the 1.2 spec is not a recommendation yet, the new combobox pattern is pretty set in stone at this point
• The browser/screen reader support for the 1.2 pattern is already much better than the 1.1 pattern, and practical accessibility should trump purity for checkers like axe
• Based on the above, I'd say it's currently a false positive

I'd guess the working draft vs. recommendation thing is the reason they haven't removed it yet. I hadn't seen any issues on that before yours though, so I don't know what their stance on it is.

[Payne-Yan]

@smhigley Their answer:

axe-core issue: dequelabs/axe-core#2478

[WilcoFiers]

The browser/screen reader support for the 1.2 pattern is already much better than the 1.1 pattern, and practical accessibility should trump purity for checkers like axe

@smhigley Do you have any data to show support for either pattern? If you're right about this, that's definitely something we should change in axe-core.

I do think there are some issues with how the data picker is implemented. Users need aria-haspopup="modal" so that screen readers can provide the correct instructions on how to interact with it, and aria-controls should be assigned to the actual modal, instead of to its parent.

[smhigley]

@WilcoFiers If you don't mind, I'm going to answer this over in the axe-core thread, since it's not specific to Fluent :)

[khmakoto]

Thanks for all your support @smhigley!

[msft-github-bot]

This issue has been automatically marked as stale because it has marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. Thank you for your contributions to Fluent UI!

[Payne-Yan]

Could you please solve this issue on the official website first? We can make a reference.

[Payne-Yan]

@khmakoto Could you please solve this issue on the official website first?

[khmakoto]

Hey @Payne-Yan, what do you mean by solving this on the official website first?

[Payne-Yan]

@khmakoto The date picker on the https://developer.microsoft.com/en-us/fluentui#/controls/web/datepicker is solved first.

[khmakoto]

@Payne-Yan, like explained by @smhigley, this happens because axe-core does not support the 1.2 standard yet. I don't think there's an actionable item on our side regarding this issue.

[Payne-Yan]

@khmakoto On the official website, click Accessibility Insights for Web tool, the pop-up box of date picker is closed directly, there is no way to reproduce it. Did you update again?