FocusVisible triggers on browser tab switch

[BartoszGamza]

🐛 Bug Report

When clicking on element and then switching tab to another and back again, isFocusVisible returns true (see gif below).

🤔 Expected Behavior

isFocusVisible should remain false when switching tabs as long as one is not using keyboard to do so. This is maybe kind of subjective, maybe its expected if so - can anyone elaborate?

😯 Current Behavior

isFocusVisible returns true

💁 Possible Solution

I've found similar error here and they resolved it by tracking document.visibilityState to detect tab switch as far as I understand their code.

🔦 Context

We are using isFocusVisible for a11y of keyboard navigation and would rather not to display the outlines when they are not expected or necessary.

💻 Code Sample

https://react-spectrum.adobe.com/react-aria/useFocusVisible.html

🌍 Your Environment

Software	Version(s)
react-spectrum	3.0.0 (but I assume the version in your docs is the latest)
Browser	Chrome (90.0.4430.72)
Operating System	OSX 11.2.3

🧢 Your Company/Team

https://www.livechat.com/

🕷 Tracking Issue (optional)

[snowystinger]

duplicate issue, but maybe something new to consider #791
@majornista anything new to be done/tried?

[devongovett]

I believe this is intended behavior. It's important for users to know where focus is when switching tabs, which is why we show the focus ring in that case.

[Andarist]

Is the intention here to have different behavior than the native :focus-visible then? If yes - this probably should be clarified somewhere in the docs since it makes sense for consumers to assume that this should match the native behavior but apparently it doesn't.

Note that if the modality would not be changed then the keyboard user would still see the focus ring when coming back to a page since it was displayed before the user switched pages. For pointer users, the focus ring would not pop up suddenly since it wasn't displayed before the user switched pages. I understand that the modality could have changed between user has switched away and back to a page and this cannot be detected reliably within the page itself but is this that important to cover? I mean - I assume that the native behavior was chosen for a reason and it was worth the tradeoff for the authors/implementers.

[devongovett]

Unfortunately, the native behavior of :focus-visible is not well specified. The spec essentially leaves it up to individual browsers on how they would like to implement it, and only offers some suggestions. We can't know whether a user is using a keyboard or mouse when switching tabs - the browser only fires a focus event with no preceding keyboard or mouse event - so we currently default to showing the focus ring. I will check with our a11y experts again though.

[Andarist]

Thanks for the answer! I would appreciate a status update when you do so and I can offer documenting the desired behavior then :)

[devongovett]

Going to re-open this. Our a11y team is not opposed to keeping the previous modality after a tab switch if we can figure out how to implement it. Sounds like it might be possible with visibility change events. If someone would like to work on a PR for that, it would be very helpful! 😃

[BartoszGamza]

@devongovett Thanks for reopening 🚀 We will try to propose a solution soon