Focus guards in floating-ui cause an aXe violation

[fabb]

Product

axe-core

Product Version

4.10.0

Latest Version

• I have tested the issue with the latest version of the product

Issue Description

Expectation

aXe should only report actual problems. Focus guards in libs like floating-ui should not cause an aXe violation.

Actual

Focus guards that use tabIndex=0 while being aria-hidden=true cause an aXe violation:

Focusable content should have tabindex="-1" or be removed from DOM

How to Reproduce

Show a tooltip with floating-ui, or alternatively add focus guards manually:

<span data-type="outside" tabindex="0" aria-hidden="true" data-floating-ui-focus-guard="" style="border: 0px; clip: rect (0px, 0px, 0px, 0px); height: 1px; margin: -1px; overflow: hidden; padding: 0px; position: fixed; white-space: nowrap; width: 1px; top: 0px; left: 0px;"></ span>

Additional context

see floating-ui/floating-ui#3364

[straker]

Thanks for the issue. @dbjorge @WilcoFiers do either of you have an opinion on how best to handle this case?

[dbjorge]

@straker This is an extension of #3430, which we fixed in #3667 by attempting to heuristically detect cases where the element in question "looks like" a focus bumper/focus guard. This specific case happens not to trigger the heuristics we're using; the right fix here would be to update the heuristics.

We may want to consider whether this should be reusing some/all of the is-visible heuristics rather than maintaining separate aria-hidden-focus heuristics; there are real failure cases where an invisible element should fail this rule, but it might be better for us to accept those as false negatives for need-review rather than continuing to play cat-and-mouse with every UI library that happens to use focus guards.

[WilcoFiers]

Yeah I'm leaning that direction too. 0-size / hidden elements with focus are suspicious enough that I don't think we'd want to fail them for having a tabindex.