-
Notifications
You must be signed in to change notification settings - Fork 776
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
New rule: flag nested interactive roles #601
Comments
Can you write this in the rules format? |
Here's a Codepen showing what happens with nested links. The browser automatically reformats nested anchor tags, but not when ARIA role="link" is wrapping an anchor tag. https://codepen.io/marcysutton/pen/YaxJVm?editors=1010# Alternative rule name: There's some language in the ARIA 1.1 specification around presentational children, which helps to clarify some of this. Browser behavior varies, even though the spec says you can't nest these roles: Chrome and Voiceover announce links nested inside of the button role, but Safari does not. I still have to test Windows but this rule makes a lot of sense to add. https://www.w3.org/TR/wai-aria-1.1/#childrenArePresentational |
What is the accessibility impact of this? The keyboard focus can move from the one element to the next. The user can interact with both. If there is no real impact, then this should be a best practice. |
The accessibility impact is that it's extremely confusing to screen reader users to hear "Link label button link" or an empty "button" because of misused HTML and ARIA. Mixing of interface controls makes them very hard to understand from a screen reader user's perspective, even if they are coincidentally still operable. As one example, when the browser changes your markup from |
The unlabelled button problem will be found by the Potential confusion problems as well as event handler propagation problems are not candidates for zero-false-positive detection Seems like a candidate for needs review at most |
How could nonconforming HTML ever be okay, especially when it presents a horrible screen reader experience? This seems like an obvious win to me. Can you provide more concrete examples of potential false positives? |
|
Nesting which results in duplication of announcements in the aural UI is a problem. For sure there are some examples where the result is sort of OK in some browsers with some AT (unknown unless fully tested), but the cost of teasing those out is worth less than accepting that the non-conforming (in HTML) nesting of interactive elements is an issue that should be flagged as an error. Here is a neat example of a label/interactive control nesting that causes multiple issues; incorrect name calc and misdirected mouse click. This doesn't appear to be caught by aXE (version 3.3) Also interactive nesting conformance errors for marcy's test page. When the DOM is tested (instead of the HTML code) the errors are reduced from 9 to 7. |
Is the argument that this is not a 4.1.1 failure after the browser fixes otherwise invalid code to generate the DOM? |
Please consider the following:
view example at - https://codepen.io/scottohara/pen/RMmyZX aXe reports no errors when testing this example. A quick test with Safari + VO (mac High Sierra), the parent button can be focused with Tab key or VO + left/right arrows, and all the content within will be announced. VO focus (using VO + left/right arrows, with quick nav on or off) can not move into the nested button to interact with the nested button specifically. Tab key will move focus to the nested button, but VO focus remains on the parent button. The focused nested button is not individually announced. I have further (much more complex) examples of nested interactive elements causing similar / other significant issues when using JAWS and NVDA. But to keep myself from writing a blog post worth of examples here, I'll save those for if you'd like further evidence. Hope this was helpful. |
Suggest that a practical approach would be to implement the conformance rules as is and loosen them as cases that are clearly not problematic are identified. |
This proposed rule is defined way too broadly. For example this is perfectly fine markup:
So IMO, we should close this issue and open specific issues for specific nestings that we know do not work EDIT: doing this would allow us to also give specific guidance as to why this is a problem |
There are a sets of rules for how interactive elements/roles can be nested defined in the HTML/ARIA/ and ARIA in HTML specs. Suggest that these are a good place to start. @dylanb btw your code example is conforming ;-) |
I was planning to start with button and link roles. How about we edit the issue instead of chucking it out and starting over? |
I just found some code related to this in the wild:
The button inside of the link causes an extra tab stop and quite a bit of keyboard confusion. After reading through ARIA in HTML that Steve so awesomely provided, I see that interactive content is not allowed for buttons nor links: Allowed ARIA roles, states and properties
axe-core should catch these and some of the ARIA cases, IMO. I can put together a list when I get back from leave unless someone beats me to it. |
@marcysutton If you are doing |
Came across this type of setup and wondering if this too would fall into this rule <ul role="menubar">
<li role="presentation">
<a tabindex="-1" href="https://foo.biz">
<span role="menuitem" tabindex="0">Foo</span>
</a>
</li>
</ul> Tested with VO and I was able to traverse to both the link and menuitem. I realize that this is slightly different than most of the above examples because they've taken the anchor out of the natural tab order but it still creates a potential confusing experience for screen reader users. Feel free to ping me for the public url I found this on |
@schne324 your case is a hybrid of my case and something else. That structure is completely broken from an ARIA markup perspective. All interim structures should be marked role="presentation" and the anchor with the role="menuitem" inside it is just plain wrong. A rule that flags that type of bad structure is different from what is being proposed here but would be very valuable. |
For a more general understanding of this, are there any guidelines on whether or not to have any nested interactions at all or not in ARIA widgets? Are there any example ARIA widgets with nested interactions. Can combobox be considered one such example? As a specific example, if someone replaces So, replacing
with
If yes, why isn't it allowed in ARIA or HTML by default? I mean why restrict this usage for buttons and links but allow for divs? |
@gaurav5430
The authoring requirements for use of ARIA in HTML define what roles can be nested within each role. |
Thanks, i understand, any interactive elements should convey a role, either by HTML semantics or by explicitly assigning aria roles, which means in this case, div inside div would be invalid, unless they are assigned aria roles.
But this also means that nested interactive elements are allowed, if we can find out the correct aria role hierarchy for them. Hence the question, if nested interactions are allowed in any case, why are they not allowed for button inside button or generally in HTML, is this only because when using nested aria roles as defined in ARIA in HTML the screenreader can parse/read it better as compared to the case of button inside button or button inside link? Or are there other usability issues in general with nested interactions, that they haven't been allowed ? |
@gaurav5430 wrote:
The constraints on nested interactive roles are based on the constraints already defined in HTML, for any roles that match built in HTML elements. not conforming in HTML
not conforming in HTML
|
Verified with the latest develop branch code base of axe-core (dated28/12/2020): and pass condition test snippet: |
Nested Interactive Roles
Ensures interactive controls are not nested so they work with keyboards and screen readers
Tags: best-practice, experimental, cat.keyboard
Help text
Ensure interactive controls are not nested.
Selector
a, button, [role="link"], [role="button"]
More info
The code sample below shows a few places where aXe should have flagged nested interactive roles. The developer in this case added a role of link with tabindex, nested a link with role=button and tabindex inside of it, and then put an input with type of image inside. That's a triple-whammy for nested controls, that we should be able to catch pretty easily since it doesn't even use click events.
Checks
The text was updated successfully, but these errors were encountered: