False positive: 'Nested-interactive' rule fails despite no negative impact with screens readers or speech recognition software

[iamrafan]

The nested-interactive rule fails on the following example despite tests with screen readers and Dragon showing no negative user impact

Demo: https://codepen.io/iamrafan/pen/KKvJywR

Product: axe-core

Expectation: Not fail nested-interactive rule/fail a different rule

Motivation: nested-interactive rule says such usages should be avoided to prevent problems when using assistive technologies, but testing with screen readers and Dragon showed no user impact

axe-core version:4.3.3

[WilcoFiers]

Can you explain what these examples intend to demonstrate? I'm seeing a good deal of problems here TBH. For starters, a very confusing accessibility tree. Here's what it looks like in Firefox:

• pushbutton "mceu_68"
  • pushbutton "Ok"
• pushbutton "mceu_69"
  • pushbutton "Cancel"
• pushbutton "No nested child"
  • text leaf "No nested child"

These are exactly what the rule says they are; nested interactive elements. You have a button inside another button. Both of them can be accessed by screen readers.

This is a very unintuitive thing about how tabindex and role=presentation work. But role=presentation only works on element that 1. are not focusable, and 2. don't have a global ARIA attribute. In this case, both those button elements are focusable, so role=presentation doesn't work.

As for why they are focusable, this is because tabindex="-1" does not turn off focus. It removes the element from sequential focus navigation, but if you click the element, target it with an anchor, or call .focus() on it with a script, that element becomes. Assistive technologies can focus elements with tabindex="-1" too. There are a few attributes that turn off focus on natively focusable elements. readonly, disable, and inert. readonly and disable aren't global attributes. They only work on a few elements, and inert is not supported by browsers yet. So the only proper way to make links inert is to remove their href.

[iamrafan]

@WilcoFiers The examples here show ok and cancel buttons used by one of our users in a dialog box, I added the no nested child button just to test if I see the same issue as in here #3227 (comment)

I tested the examples with the following ATs/browsers in both modes and could not find any negative user impact:

• Edge/NVDA
• Chrome/NVDA
• Firefox/NVDA
• Edge/JAWS
• Chrome/JAWS
• Edge/Narrator
• Chrome/Narrator
• Safari/Voiceover
• Dragon NaturallySpeaking

So based on the testing and due to lack of finding any user impact from the end user perspective on the current examples in the current state, I feel failing failing this rule with the current failure messages is not appropriate.

This would feel like a false positive as I see a message saying Using a negative tabindex on an element inside an interactive control does not prevent assistive technologies from focusing the element (even with 'aria-hidden=true')" but when I test it with ATs, I find that the assistive technologies usage is not being impacted

May be it is worth checking if new failure messaging needs be added or if a few failures need to be made needs review based on the impact found by end user testing

We also understand that this is a parsing violation but this rule does not reference that.

[WilcoFiers]

@iamrafan There are several ways to get both to the outer button, and the nested one. In Safari+VO for example, if you use tab navigation you get to the outer button, and if you use reader mode you can get to the inner button. Your colleague @scottaohara recently got involved in this too, arguing in favour of keeping this part of the rule in:
#3159 (comment)

I get that this pattern seems like it should work, but the spec don't allow it, and screen readers don't handle it well.

[scottaohara]

can do it here as well.

[WilcoFiers]

Yeah. Really wish it wasn't a problem. It's counter-intuitive, and hard to explain. But it's an issue. Thanks for weighing in Scott.