New rule: flag nested interactive roles

[marcysutton]

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.

<div role="link" tabindex="40" title="link label">
  <a href="/url-went-here" title="link label" role="button" tabindex="12">
    Link label
    <div class="link-icon">
        <input type="image" alt="add to stop throwing error">
    </div>
  </a>
</div>

Checks

• none: nested-interactives

[WilcoFiers]

Can you write this in the rules format?
https://github.com/dequelabs/axe-core/blob/develop/doc/rule-proposal.md

[marcysutton]

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: dont-do-it 😂

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

[dylanb]

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.

[marcysutton]

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 <button><button>Text</button</button> to <button></button><button>Text</button>, you end up with an unlabeled button. We could nip these problems in the bud with a dedicated rule.

[dylanb]

The unlabelled button problem will be found by the button-name rule (the beauty of testing the DOM)

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

[marcysutton]

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?

[dylanb]

<h2>Very broken</h2>
<p>This group of inputs is very broken because only the fake link can be triggered</p>
<div role="link" tabindex="0" title="link label" onclick="event.stopPropagation();event.preventDefault();alert('clicked fake link')">
  Link Text
  <a href="/url-went-here" title="link label" role="button">
    Role=["button"] Text
    <div class="link-icon">
        <input type="image" alt="add to stop throwing error" onclick="event.stopPropagation();event.preventDefault();alert('clicked input')">
    </div>
  </a>
</div>
<H2>Not as broken</h2>
<p>This group of inputs is less broken because both the link and the button can be triggered</p>
<a href="/url-went-here" title="link label" role="button">
    Role=["button"] Text
  <div class="link-icon">
    <input type="image" alt="add to stop throwing error" onclick="event.stopPropagation();event.preventDefault();alert('clicked input')" />
  </div>
</a>

https://codepen.io/holistica11y/pen/EEzVYy

[stevefaulkner]

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.

[aardrian]

Is the argument that this is not a 4.1.1 failure after the browser fixes otherwise invalid code to generate the DOM?

[scottaohara]

Please consider the following:

<button>normal button</button>

<div role="button" tabindex="0">
  Parent button
  <div role="button" tabindex="0">
    Nested button
  </div>
  <p>Just some more content here.</p>
</div>

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.

[stevefaulkner]

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.

[dylanb]

This proposed rule is defined way too broadly. For example this is perfectly fine markup:

<ul role="menubar">
    <li aria-haspopup="true" role="menuitem" tabindex="0">
        One
        <ul role="menu">
            <li role="menuitem" tabindex="0">
                  One One
            </li>
...

menuitem is defined as a widget role and having menuitems as children (ultimately) of other menuitems is actually encouraged.

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

[stevefaulkner]

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 ;-)