[popover] moving keyboard focus out of a popover should dismiss it

[brucelawson]

Currently, clicking outside a popover dismisses it. However, using the keyboard to tab through links in a popover, and then to the next link outside the popover does not dismiss it. This means that if the next focussable element is 'underneath' the still-exposed popover, it is not visible.

This doesn't fall foul of WCAG SC 2.4.11 because "If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered visually hidden due to author-created content.", and esc will light dismiss the popover. However, it feels annoying and inconsistent.

Should a popover light-dismiss when keyboard focus leaves it? I think so, if it does when mouse pointer leaves it.

Should we create a new declarative way to achieve light dismiss when focus leaves a popover?

[lukewarlow]

See #415 for prior discussions.

Going to update the description a little to make this a discussion about an opt-in way to achieve this declaratively.

[brucelawson]

For context, I did try to reason about this the other way around and {nav popover focustrap} but then I figured that opens up more wormcans, and in any case popover is so new there's unlikely to be a corpus of web content that would break because it expects a popover to close on click outside/ esc but relies on it remaining open if keyboard focus goes outside.

[scottaohara]

the tldr; of it is that there are types of popovers which should automatically light dismiss when keyboard focus leaves (a custom listbox popup, or a sub-navigation list), and then there are those that shouldn't (non-modal dialog chat windows, some instances of disclosure widget / tip-like popups that describe UI and users may need to refer to it as they type). it's far easier for developers to add light dismiss behavior to popovers than it is for them to remove that behavior if it was baked in.

we absolutely should add a declarative way to allow popovers to light dismiss when focus leaves them. and just make sure that when added, it's very clear to authors when to use this feature vs not.

[brucelawson]

disclosure widget / tip-like popups that describe UI and users may need to refer to it as they type

I hadn't thought of that; makes total sense. Cheers Scott.

[gregwhitworth]

Closing based on @brucelawson seeming content with the prior resolution. @brucelawson please re-open if you disagree :)

[lukewarlow]

This issue is still useful to discuss an opt in mechanism for this.

[lukewarlow]

@josepharhar the answer to the question you raised should be above. I think it's that it can't be the default because it's not always the behaviour you'd want. I'm many cases it is needed and I believe we should have and discuss a declarative solution to this.

[josepharhar]

I kind of feel like if you're using popover=auto and you can therefore light dismiss with mouse then it means you should also light dismiss with keyboard navigating out of the popover, but I guess that adding a new opt in would also make it easier to ship since there would be no risk of breakage.

[scottaohara]

for further context - light dismiss on focus out was explicitly called out as being a potential problem when going over that feature with Aaron Leventhal (google a11y), was mentioned as an accessibility/usability concern when discussing with people from Vispero (makers of JAWS screen reader), as well as when talking about this with coworkers of mine who use screen readers. The light dismiss via mouse was deemed less problematic (though still could be problematic for people with motor disabilities who may be prone to accidental clicks/taps outside of a popover) - but at least if one can see, then they would likely to be more aware of their accidental dismiss.

The problem is that some types of popovers (e.g, a select's listbox popup and other form control 'pickers') do dismisses on focus leaving (hence why people should want to do this, when appropriate) - but because popover can be applied to anything, for many of those instances it would be unexpected behavior to have the content one just 'expanded' auto collapse on them. It could have resulted in people constantly dismissing the content they were attempting to interact with, because tab key just let them leave the popover. In the end, a popover applied to a div, a UL, or an article is providing top layer presentation to these elements. They aren't otherwise special, AT isn't specifically calling out that they're 'popovers' (at least not last i checked - nor was there much anticipation they would be when we were shipping popover - though i often tried to ask for this sort of announcement). Essentially, from a screen reader user's pov, they're little different than if someone were to have a standard in-page disclosure (show/hide) widget. And those are not at all expected to auto dismiss when tabbing away from them.

In other words, we did not add auto dismiss to popovers on focus out specifically for accessibility.

Additionally when mason, aaron and i were going through this, we generally agreed that it would be far easier for developers to add the auto dismiss functionality with JS (it is rather trivial considering all the things popover has done for the developer, by default), than it would be for developers to suppress the behavior.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.