dequelabs / axe-core

Accessibility engine for automated Web UI testing
https://www.deque.com/axe/
Mozilla Public License 2.0
5.99k stars 779 forks source link

aria-required-parent misapplied to menubar role #3103

Open jrpool opened 3 years ago

jrpool commented 3 years ago

Product: <<axe-core | axe Extension | axe Linter>> axe-core Expectation: << Describe what you expect the product to do >> Product should not apply aria-required-parent to menu and menubar in relation to menuitem roles, because elements with menuitem role are valid if descendants of elements with menu or menubar role, regardless of whether the menuitem element is a child of the menu or menubar element. Nonparent ancestry establishes the required ownership. Actual: << Describe what the product actually does >> The product insists on parent ancestry with menu and menubar in relation to menuitem roles. Motivation: << Describe why you want the behavior to be changed >> The critical issues announced by the product for menuitem elements with menu or menubar non-parent ancestors are false positives. They exceed the ARIA specification.


axe-core version: 4.3.1
axe-webdriver, extension or other integration version: X.Y.Z

Browser and Assistive Technology versions
Chrome 92.
For Tooling issues:
- Node version: XX  
- Platform:  
straker commented 3 years ago

Thanks for the issue. Could you provide a small sample of the HTML code that produces the error? Mostly I want to see what you mean by non-parent ancestry (I assume menubar > div > menuitem, but want to verify).

jrpool commented 3 years ago

Thank you for your request for clarification, @straker.

Strangely, in new testing I am finding axe-core making this mistake with both menu and menubar roles, although previously it was doing that with menubar roles only. I no longer have the original code. So I have edited the initial comment accordingly.

An example of code to demonstrate this issue is at https://jpdev.pro/jpdev/blog/entries/0000/axebug.html.

WilcoFiers commented 3 years ago

@jrpool This is not a mistake. This rule is an implementation of the W3C's ARIA required context role rule, which is required for WCAG 2.x. (Full disclosure, I helped to write this.)

You're correct in saying that ARIA allows having the menuitem as a grandchild of menu, and have some other role in between them. But "allow" here is more in the sense that it isn't strictly prohibited. The reality of it is that it causes problems. The ARIA practices all either ensure this parent / child relationship is preserved, or ensure that the DOM node sitting in between the grandparent and child is not included in the accessibility tree; for example by putting role=none on it. Axe-core allows for this too.

The ARIA working group is actively working to change this. I was one of the people who raised it with them, and they are planning to address this in ARIA 1.3. You can see some of that work happening here: https://github.com/w3c/aria/pull/1454/files

jrpool commented 3 years ago

Thanks for explaining this, @WilcoFiers. In the meantime it might be useful to put a comment somewhere saying that this rule is a bit stricter than the ARIA requirements for menuitem, so people like me will not perceive a bug and will also be advised to structure menus more robustly than they otherwise might.

WilcoFiers commented 3 years ago

Fair point. I'll see about updating the help page.