[openable] focus management behaviour

[lukewarlow]

We need to further define the focus management behaviour for openables. While they don't take focus by default as described here. Should they adjust focus order such that the openable is next in the tabindex (like popover)?

[css-meeting-bot]

The Open UI Community Group just discussed [openable] focus management behaviour, and agreed to the following:

• RESOLVED: Copy popover focus management behaviour (investigate use cases for opt-out).

The full IRC log of that discussion

<scott> q+
<keithamus> lwarlow: Currently the explainer says something like: openable does nothing regarding focus. If you had a button at the top of your DOM and you have an openable thats at the end but visually next to it, do you want it to be the next tab stop? It shouldn't claim focus, but maybe it should move itself in the tab order?
<keithamus> lwarlow: either would be fine
<masonf> ack scott
<keithamus> scott: it should share the same behaviour, there are cases where it's needed. A button to open the navigation in the top banner of a website, but due to the page construction the nav is a sibling to main, if you dont have the automatic tab restructuring someone opening that would have to navigate through the other items in the top banner, and would
<keithamus> be unlikely to know if it was open or not
<sorvell> openable="autofocus" ?
<keithamus> scott: likewise aria-details association would be needed
<keithamus> scott: I would want the similar tab restructuring
<lwarlow> Proposes Resolution: Copy popover focus management behaviour.
<brecht_dr> +1
<keithamus> +1
<keithamus> masonf: <describes popover focus management behaviour>
<sorvell> -1 without an opt out
<keithamus> sorvell: I think it's fine, I don't mind the default, but I'm not convinced it's always needed- if it does this and I don't want it I have to give up using the feature
<keithamus> masonf: is there a use case example you could give where it might be a bad idea?
<keithamus> sorvell: toast?
<keithamus> masonf: toasts are never triggered by a button right?
<lwarlow> q+
<keithamus> scott: likely would be a manual popover, not this
<keithamus> lwarlow: manual popovers don't have the focus behaviour?
<keithamus> masonf: I think they do if triggered by a button
<keithamus> scott: so a toast could be triggered by a button, but relatedly, not directly. Other apis going on and stuff
<keithamus> masonf: there's an easy workaround: you call showPopover yourself, and dont give it a source element, and it won't do the focus fixup element
<keithamus> masonf: does that resolve your -1?
<keithamus> sorvell: I'll change my -1 to 0
<keithamus> sorvell: I'm a little concerned with it being like a toast or some other API, but I don't have a good use case and it seems there's a workaround
<lwarlow> RESOLVED: Copy popover focus management behaviour (investigate use cases for opt-out).
<keithamus> masonf: maybe lwarlow can add the workarounds to the explainer

[mfreed7]

I'm tentatively removing Agenda+ - feel free to put it back if you'd like to discuss this again.