[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.