-
Notifications
You must be signed in to change notification settings - Fork 772
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
<ul role="menubar"> not recognizing <li><a role="menuitem"></a></li> as a descendent #1171
Comments
Thanks for reporting. I'm quite surprised that this seems to work. I've seen different cases where, unless there is a role=presentation or role=none on the element between the owner and the owned element, the screen reader can't work out how many items are in that group. Testing the example in VoiceOver gets me a correct count, so it seems something more is going on there. Have you tried testing this in NVDA or JAWS? Do they give you a correct count of menu items? |
@WilcoFiers I don't have access to NVDA or JAWS, so I'm not sure... but I have seen what you mentioned in VoiceOver. |
Update: I've done a bunch of research. There is quite a bit going on that I wasn't aware of. I'm working to reverse engineer the algorithms used to come up with this list of owned elements, so that axe can correctly identify what elements belong where. It'll take some time to get this done, but it's high on my priorities list. |
@bbAdam After further testing we discovered that there are issues with this pattern. Most notably NVDA + Firefox does not support this method. Because of the orphan list items, each menu item is counted as a list of 1. An issue has been filed with the ARIA working group to fix the example. We are going to look at how we can better expose this information through axe-core, so for that purpose I'm keeping this issue open. I'm removing the "bug" label from it though, as this technique not working in Firefox means it doesn't meet the baseline for accessibility support in axe. |
I ran into this same issue with different roles, so I thought I would mention it here to be safe and not create clutter with another ticket. The tab accessibility (https://www.w3.org/TR/wai-aria-1.1/#tab, "Authors MUST ensure elements with role tab are contained in, or owned by, an element with the role tablist.") indicates that should be valid. In particular, it's used by a fairly popular bootstrap/angular component library called ng-bootstrap (https://ng-bootstrap.github.io/#/components/tabset/examples). Thanks! |
I am seeing the same violation as @smithk58 above. It looks like axe flags this whenever the wrapping |
I'm having the same issue with <div id="question">Question</div>
<ul role="radiogroup" aria-labelledby="question">
<li><label><input type="radio" id="one" name="one" /> One</label></li>
<li><label><input type="radio" id="two" name="two" /> Two</label></li>
<li><label><input type="radio" id="three" name="three" /> Three</label></li>
</ul>
https://dequeuniversity.com/rules/axe/3.2/listitem?application=axeAPI If I try wrapping the
|
@lukescott put @WilcoFiers I think we should close this as it works correctly |
@dylanb - I have to disagree assuming this project intends to conform to the w3c standards. I linked directly to an example of them saying what I posted should be valid. It's not even slightly ambiguous, as they link directly to their definition of "owned" where it says any descendant. If the project doesn't want to conform to the standards fully that's definitely not up to me to decide (I understand it's not simple), but I thought I should emphasize that since you might not have visited the link. Thanks! |
@smithk58 Apologies, I never saw that response. There is no good definition in any W3C specification about owned elements at the moment. Browser are inconsistent about this, which is why I would not recommend doing anything other than a direct parent-child relationship. It is not cross-browser compatible. There is an issue open for this on the ARIA spec, it's tagged for WAI-ARIA 1.2, so hopefully this can be resolved at some point. w3c/aria#1033 |
It seems that the issue is that the The problem is not that the different roles of I believe that the fix is to update the error message to include that the
|
@WilcoFiers - No worries, thanks for responding! I might be overlooking something, but isn't w3 the source for defining them (I could be super wrong about that)? If so, they so have a definition of owned: https://www.w3.org/TR/wai-aria-1.1/#dfn-owned-element. My apologies if I'm wrong or overlooking something and wasting your time though. Either way, if browsers aren't following that consistently I could see how that makes copying it a bad choice, even if it's closer to the spec. |
I think there are subtle but important differences between putting a group role and a presentation role on a The ARIA 1.1 entry for the presentation/none role specifically states that it will remove the semantics from the element itself as well as its required owned elements. The spec does not say that when you repurpose an element with required owned elements using the role attribute that its required owned elements are automatically changed or their implicit semantics should be removed. so
should be flattened to a bunch of divs, and this is pretty well supported across browsers and a.t. but
is different. |
Here , after all of the above suggessions tried, I observed,
Which is actual behaviour of |
@padmavemulapati Please reach out to the developer once again and close this ticket asap. |
parent element do not have an overriding role, so<role = menu> is passing and the remianing roles failing (even <role=menubar>) |
In the version 3.5 chrome extension update from 9/25/18, a menu structure like the following:
Throws the following flag:
This is inconsistent with the specs layed out here: https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-1.html
If the menuitem role is moved to the list item, the flag goes away.
It appears as though the AXE algorithm is only looking for Direct Decedents to have the role of menuitem, instead of any descendent of the parent menubar.
https://www.w3.org/WAI/PF/aria/roles#menuitem states that "Authors MUST ensure that menu items are owned by an element with role menu or menubar in order to identify that they are related widgets. Authors MAY separate menu items into sets by use of a separator or an element with an equivalent role from the native markup language."
and an owned element is defined as "any DOM descendant of the element, any element specified as a child via aria-owns, or any DOM descendant of the owned child." here: https://www.w3.org/WAI/PF/aria/terms#def_owned_element
Issue can be seen here: https://templatelibrary.schoolwires.net/academy
I am a web developer for Blackboard, Inc. and we have hundreds of sites out there that are now getting this flag. Thank you for looking into it!
The text was updated successfully, but these errors were encountered: