Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

Thanks for the pr. Unfortunately I don't think this works as expected. Using display: none removes the element both visually and from the tab order, while aria-hidden does neither of those. Testing this out in different screen reader / browser combinations:

<div role="button"><button aria-hidden="true">My Button</button></div>

• IE / JAWS - Can tab to the button and is read as "Unlabeled 0 button"
• Edge / JAWS - Can tab to the button and is read as "My Button, button", activating the button moves focus off of it
• FireFox / NVDA - Can tab to the button and nothing is read out, sometimes just "blank"
• Safari / VO - Can tab to the button and is read as "button" (no label). Furthermore you can press "down" to enter the text and "My Button" is read.

However, as to whether or not this particular case should fail the nested-interactive rule, we'll need @WilcoFiers opinion.

I agree the correct combination would be aria-hidden="true" and tabindex="-1" as explainend in
accessibilityinsights.io → aria-hidden-focus

• Element with aria-hidden="true" contains only focusable elements that are disabled or not tabbable

For me this is a variant of the same thing but I don't know if you shared this opinion.

So talking with Wilco we determined that since the example fails aria-command-name and aria-hidden-focus, it doesn't also need to fail nested-interactive. Furthermore, since the description of the rule is Nested interactive controls are not announced by screen readers, adding aria-hidden=true passes this description as the button is no longer announced to a screen reader.

Tested the following snippet with a colleague the other day - with Dragon both checkboxes in the following markup snippet were still exposed;

<div role=checkbox aria-checked=true tabindex=0 aria-label=foo>
  <input type=checkbox aria-hidden=true tabindex=-1> <!-- visually hidden -->
</div>

Using VoiceOver and the down arrow key alone to read line-by-line, the visually hidden checkbox is still reached, causing a focus stop without an announcement.

While screen readers are trying to error correct for author blunders like these, it's not bullet proof across all other AT - more of which still needs testing.

For instance, testing the proposed 'passing' snippet specific to this issue with Edge/Narrator, Narrator can reach the outer button and it will be announced with no name (which makes sense because the 'pass' is within the nested button that's set to aria-hidden=true). Navigating again, Narrator will then reach the nested button (even though it's aria-hidden/tabindex=-1) and announce "pass, button")
https://codepen.io/scottohara/full/wveyWWK

I'd request that this be taken into consideration before passing stuff that can still pose issues, and would not discourage authors from poor coding practices.

Thanks

Apologies for the slowed response. I've been a little reluctant to dive into this. Scott is right in that this pattern just doesn't work very well, and that you probably just shouldn't use it.

I think what needs to happen is that we create a new failure message, specifically to explain that using negative tabindex can still cause problems. I'll create an issue for this.

I believe this pr is replaced by #3194, since we don't want tabindex=-1 to pass but now warn of the problem.

Going to close this issue. Negative tabindex will now produce a warning stating that it won't prevent assistive technologies from focusing the element. In terms of the number of rule failures, I believe all 3 should be reported for the following reason:

If the user starts with this HTML:

<div role="button"><button aria-hidden="true">My Button</button></div>

We report 3 failures: aria-hidden-focus, button-name, and nested-interactive. So the user then does the following to "fix" the problem:

<div role="button" aria-label="My Button"><button tabindex="-1" aria-hidden="true">My Button</button></div>

Which should correctly produce a nested-interactive failure with the message warning of tabindex=-1. If we were to prevent nested-interactive, the user wouldn't know the 2nd solution still has a problem. So it's better that all 3 fail the first time as they are all 3 different problems on the structure.