Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Payne-Yan opened this issue Aug 24, 2020 · 10 comments
Closed
Labels
feat New feature or enhancement rules Issue or false result from an axe-core rule
Milestone

Comments

@Payne-Yan
Copy link

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

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


axe-core version: 3.5.1
chrome extension -> Accessibility Insights for Web: 2.20.0
@Payne-Yan
Copy link
Author

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.
    image

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
Copy link
Contributor

straker commented Aug 24, 2020

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
Copy link
Contributor

smhigley commented Aug 27, 2020

(I'm mostly responding to @WilcoFiers' comment over here: microsoft/fluentui#14461 (comment))

@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): w3c/aria-practices#1255 (review). 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
Copy link
Contributor

@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.

@WilcoFiers WilcoFiers added this to the axe-core 4.1 milestone Aug 28, 2020
@mcking65
Copy link

mcking65 commented Sep 2, 2020

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
Copy link
Contributor

smhigley commented Sep 2, 2020

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
Copy link

jnurthen commented Dec 5, 2020

@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
Copy link
Contributor

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

@WilcoFiers WilcoFiers modified the milestones: axe-core 4.2, axe-core 4.3 Feb 24, 2021
@WilcoFiers
Copy link
Contributor

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

@WilcoFiers WilcoFiers added feat New feature or enhancement rules Issue or false result from an axe-core rule labels Apr 14, 2021
@WilcoFiers
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or enhancement rules Issue or false result from an axe-core rule
Projects
None yet
Development

No branches or pull requests

6 participants