[focusgroup] Should elements with `tabindex="-1"` participate in focusgroup navigation when focused?

[sb3nder]

Issue #1314 resolved to add the focusgroupstart property, which determines which element receives focus when entering a focusgroup. This change freed up the use of tabindex="-1" for other purposes.

Option 1

In #1314, @janewman suggested:

An element with a tabindex="-1" would not be considered a focusgroup item and would not be managed by focusgroup at all.

I agree that an element with tabindex="-1" should not be reachable via directional navigation. However, I am unsure whether it should be excluded from directional navigation once it is focused by other means.

It’s not clear to me, how common the use case is for elements that are only programmatically focusable (via tabindex="-1") but should still participate in a focusgroup once focused.

Developers could still remove the tabindex on focus and reapply it on blur, while also adding the appropriate role property.

---

Option 2

An element with tabindex="-1" would not be reachable via directional navigation, but once focused, it would still participate in the focusgroup.

To achieve the same behavior as Option 1, focusgroup="none" must be added:

<div focusgroup="toolbar">
  <button tabindex="-1" focusgroup="none">btn</button>
</div>

For container elements, the same behavior as Option 1 cannot be achieved without introducing a new property (e.g., focusgroup="remove") or defining a special meaning for tabindex="-2".

Here, directional navigation works when the div is focused, unlike Option 1.

<div focusgroup="toolbar">
  <div tabindex="-1">
    div
    <button>btn</button>
  </div>
</div>

Adding focusgroup="none" removes both the div and the button, which does not reproduce the same behavior as only tabindex=-1 as Option 1:

<div focusgroup="toolbar">
  <div tabindex="-1" focusgroup="none">
    div
    <button>btn</button>
  </div>
</div>

If the container behavior in Option 1 is important, perhaps it could be reproduced with a different syntax, such as:

<div focusgroup="toolbar">
  <div tabindex="-1" focusgroup="remove">
    div
    <button>btn</button>
  </div>
</div>

[janewman]

It’s not clear to me, how common the use case is for elements that are only programmatically focusable (via tabindex="-1") but should still participate in a focusgroup once focused.

This does introduce an asymmetrical behavior where while you can move from the element with tabindex=-1, you cannot return to it except via the mouse or programatic js. In the end this is similar to how the same attribute works for sequential (tab) navigation, but I can't immediately think of a control that behaves this way today and feel this would be quite confusing to a user.

I've got a slight preference for not allowing this but am not fundamentally opposed as this behavior would be following the pattern set by sequential (tab) navigation. I think I'm missing the value this would give authors when considering the asymmetrical behavior this could give users, but maybe I just haven't seen the right example.

[css-meeting-bot]

The Open UI Community Group just discussed [focusgroup] Should elements with `tabindex="-1"` participate in focusgroup navigation when focused?, and agreed to the following:

• RESOLVED: Elements with tabindex="-1" participate in focusgroup navigation when focused

The full IRC log of that discussion

<keithamus> scribe+
<keithamus> Jacques1: about whether elements with tabindex=-1 should participate in focusgroup when they are focused
<keithamus> Jacques1: focusgroup was only considering elements which are keyboard focusbale as participating in the focusgroup
<lwarlow> q+
<flackr> q+
<jarhar> Jacques1: asymmetrical behavior with tab navigation. with focusgroup being used to replace controls, it might be confusing. say you open a menu and youre focused on one of these items. if you use your arrow keys to move off of it and then cant get back to it, it seems confusing. tabindex=-1 doesn't seem as strange.
<jarhar> Jacques1: not being able to navigate back to something thats tabindex=-1
<jarhar> lwarlow: if youre focused on an element with tabindex=-1 and youre inside a focusgroup, it should become a focusgroup member so that you can use arrow keys to get to the next item
<jarhar> lwarlow: yes it might feel weird that you cant get back to it with arrow keys, but thats already true of tab
<jarhar> lwarlow: theres patterns this enables
<jarhar> lwarlow: its not necessarily a good thing, but you might have a select input. you sometimes have a no options selected as your initial item. that might be you focus that initially but you dont want users to be able to go back to that invalid option
<jarhar> lwarlow: otherwise you might want to remove that as an option
<jarhar> lwarlow: just to be consistent with tab it feels ok
<keithamus> ack lwarlow
<jarhar> q+
<jarhar> lwarlow: if you press tab while youre on this and its not part of the focus group, its going to do something strange
<jarhar> Jacques1: i was just testing my current implementation, and i think it would exit the group based on memory. i get that its strange. were not talking about adjusting the way that tab is working, just that using arrow keys
<flackr> https://open-ui.org/components/focusgroup.explainer/#guaranteed-tab-stop
<jarhar> flackr: i checked the explainer and maybe its out of date, but if you want to implement a roving tabindex control, you set tabindex=-1 on every element in the focusgroup
<jarhar> Jacques1: i think thats the old focusgroup explainer
<jarhar> flackr: if thats no longer the case then my objection goes away
<jarhar> flackr: do we have a roving tabindex pattern?
<jarhar> Jacques1: the way it works right now is that you dont set tabindex=-1, instead focusgroup removes all but one from sequential tab navigation. when you hit tab, it goes only to keyboard focusable items, but only one of them
<jarhar> Jacques1: its a flip from the old previous explainer
<jarhar> flackr: in that case your proposed behavior sounds consistent with tab
<jarhar> flackr: you can click and then use the keyboard to change focus and you cant get back to it
<keithamus> q+ sorvell
<keithamus> ack flackr
<keithamus> jarhar: I think for tab there's the sequential navigation starting point. It doesn't have to be tabindex=-1 it can be anywhere
<keithamus> flackr: thats correct
<keithamus> flackr: what's the context?
<keithamus> jarhar: it might be helpful to know if this is something similar but I don't know much about focusgroup
<jarhar> Jacques1: i really hesitate to make focusgroup touch any of those things
<bkardell> q?
<keithamus> ack jarhar
<jarhar> Jacques1: the way ive been thinking about focusgroup is that its simply removing things from sequential focus order, gets a lot simpler than making focusgroup interact with all these things
<lwarlow> q+
<jarhar> sorvell: what is this issue about?
<jarhar> Jacques1: *explains current discussion*
<jarhar> sorvell: isnt there another attribute thats focusgroup none?
<jarhar> Jacques1: that remains
<jarhar> sorvell: is that duplicative with tabindex=-1?
<keithamus> ack sorvell
<castastrophe> q+
<jarhar> Jacques1: theyre a little bit different. focusgroup none affects subtree. you could have another interesting thing within a focusgroup that doesn't need to be managed by the focusgroup. once you do have focusgroup, it is participating if you have tabindex=-1. focusgroup none means it will never participate
<jarhar> sorvell: i wanted to mention the start thing. my concern is that this seems sort of like positive tabindex
<jarhar> sorvell: in that its controlling/altering the normal tabbing behavior
<jarhar> sorvell: for all intents and purposes, positive tabindex is strongly recommended against, so why isnt this start thing also a bad idea?
<jarhar> sorvell: if you want to do this differently then make your dom different
<nmn> q+
<jarhar> Jacques1: i know we've discussed this in previous meetings. the thing that comes to mind is lets say youre making a radio control and you want the selected element
<nmn> q-
<castastrophe> q-
<jarhar> Jacques1: by using this focusgroup start you set that attribute and thats the one that focus jumps to. users would be confused if you had to start at the top every time or reorder your radio to make your dom match
<jarhar> sorvell: its tied not to focus but to selection in that case
<jarhar> Jacques1: focusgroup doesn't watch or manage selection
<jarhar> sorvell: its promoting the notion of focus to have that same capability as some kind of selection state
<jarhar> sorvell: the native focusgroup thing that we have, radio, it has a concept of selection. the selection is the thing that gives is priority, not focus
<jarhar> sorvell: it worries that were giving focus too much power
<jarhar> sorvell: to specify what should be selected
<nmn> q+
<jarhar> sorvell: this is very rough but that just worries me slightly
<jarhar> sorvell: i really didnt like the idea of multiple starts
<jarhar> sorvell: to me this indicates that youre getting back to the territory of - the next thing is making a numerical thing which is positive tabindex
<jarhar> sorvell: if its just one then thats ok, but if its more then one thats bad
<jarhar> Jacques1: if the author puts more than one then we pick the first one in dom or reading order
<jarhar> Jacques1: if you have more than one its an error
<jarhar> lwarlow: yes for radio buttons its selection that decies where you go back to. if you want to implement selection follows focus, to do that declaratively you need this attribute
<jarhar> lwarlow: unless you have a before focusgroup enter that you can use to programatically focus the thing which feels messy
<jarhar> lwarlow: the attribute is much nicer
<flackr> q?
<flackr> qq+
<jarhar> lwarlow: it also allows you to work around certain cases where your control would go back to would not work because it has arrow key behavaior you want to avoid
<keithamus> ack lwarlow
<jarhar> lwarlow: you want your input to be the last thing in your group
<jarhar> lwarlow: using this you can work around that
<jarhar> lwarlow: assuming this overrides memory
<jarhar> flackr: whats wrong with using the selected attribute?
<jarhar> lwarlow: because it doesn't work on custom elements or various other elements?
<jarhar> flackr: we're inventing attributes as it is
<sorvell> qq+
<jarhar> lwarlow: selected has a specific meaning for other elements
<keithamus> ack flackr
<Zakim> flackr, you wanted to react to sorvell
<jarhar> lwarlow: maybe it should be current instead of selected?
<jarhar> sorvell: i think this helps to refine my initial point. is the start concept giving too much power to focus? a radio button, when selected, it is visibily indicated at all times, not just focused.
<jarhar> sorvell: going to a specific spot should - is more like - indicating that im going to the thing thats selected
<jarhar> sorvell: with focus, author has to make sure that the user can tell its selected
<keithamus> ack sorvell
<Zakim> sorvell, you wanted to react to lwarlow
<jarhar> sorvell: maybe we should explore a selection state that would bring this functionality to the table
<jarhar> lwarlow: if we try to tie this to selectedness, then the whole thing will fall apart. we had css toggles where we tried to do this sort of thing
<jarhar> lwarlow: i worry that if we try to overindex on the two, that will break this for things where selectedness is not relevant
<jarhar> lwarlow: base appearance listbox is a focusgroup. there is no selectedness as part of that, its a separate concept
<jarhar> lwarlow: tbh that model is far better for users. radios are bad in their current design
<jarhar> lwarlow: this feels more akin to autofocus than positive tabindex
<jarhar> lwarlow: its scoped to the parent focusgroup
<jarhar> lwarlow: positive tabindex is document scope
<jarhar> lwarlow: scoped to narrow usecases like toolbars
<jarhar> lwarlow: this pattern should help people stop using positive tabindex
<jarhar> nmn: luke said 90% of what i was going to say. i think autofocus comparison is what i was going to bring up as well
<jarhar> nmn: there are also things where selection doesn't follow focus
<keithamus> ack nmn
<flackr> q+
<nmn> q+
<jarhar> lwarlow: i think we have two proposed resolutions
<jarhar> nmn: are we planning to add any attribute to the currently focused element when you move it around with arrow keys?
<jarhar> everyone: no
<sorvell> q+
<keithamus> ack nmn
<keithamus> ack flackr
<jarhar> flackr: so this isn't selection, is this a more general thing than a focusgroup start? is that the most generla attribute we would use
<jarhar> flackr: what happens in the future with other things that have some initially interesting thing?
<jarhar> Jacques1: is this a naming question?
<jarhar> flackr: yes
<jarhar> flackr: if we have something else that is like this for another feature, could be confusing? thats my only concern
<jarhar> Jacques1: ive heard some people say it should be focusgroup start
<jarhar> Jacques1: i dont have a strong opinion here
<nmn> qq+
<jarhar> flackr: maybe its fine to keep it as a focusgroup attribute
<keithamus> ack nmn
<Zakim> nmn, you wanted to react to flackr
<jarhar> nmn: we already have autofocus, and we could add a value to that attribute
<jarhar> flackr: thats not bad
<jarhar> flackr: might have compat issues
<keithamus> q+ sb3nder
<jarhar> nmn: it could be groupautofocus
<lwarlow> focusgroupautofocus="bruce"
<jarhar> sorvell: since we brought up focus follows selection, is there good support in focusgroup for not doing that pattern?
<keithamus> ack sorvell
<jarhar> sorvell: if i dont do selection follows focus, and i focus something else but dont select it, and i come back, i want the selected item to be focused. is there a good way to do that?
<lwarlow> q+
<jarhar> Jacques1: focusgroup doesn't know anything about selection. as the author, when you set selection, you need to tell focusgroup with this attribute
<jarhar> Jacques1: the default is that when you go back to the focusgroup it uses memory
<jarhar> Jacques1: you can tell the focusgroup no memory
<jarhar> Jacques1: the author can change these attributes dynamically
<jarhar> sorvell: if i do no memory, does it always go back to the start?
<jarhar> Jacques1: yes
<lwarlow> q-
<jarhar> sbender: is it the first focusgroup start for the whole group?
<jarhar> Jacques1: it would be per segment
<keithamus> ack sb3bnder
<keithamus> ack sb3nder
<jarhar> Jacques1: if you have focusable content and you opt out in the middle of the focusgroup theres segments
<jarhar> Jacques1: if you hit tab to enter opted out content, rather than skip, the current explainer reenters the focusgroup has multiple entry points
<jarhar> Jacques1: its a bit of complexity, but it ensures authors always have control over whats going to be focused when you enter the focusgroup
<jarhar> sbender: feels overcomplicated
<lwarlow> Seems reasonable, most people won't need to care about segments.
<jarhar> Jacques1: yeah i have examples i can show
<jarhar> Jacques1: segments operate independently but you can use arrow keys to go across it
<sorvell> I like autofocus="group"
<lwarlow> Proposed Resolution: Elements with tabindex="-1" participate in focusgroup navigation when focused
<jarhar> Jacques1: what im hearing is that yes we should have it, if youre focused on an element with tabindex=-1, keyboard focus should be able to move off of it but not back onto it
<sorvell> q+
<jarhar> sorvell: i dont think thats how radio groups work. i would love it if it the explainer diverged from how radios work
<jarhar> sorvell: it should explain why
<jarhar> sorvell: we're introducing segments that dont exist in radio groups
<jarhar> Jacques1: we have an issue that goes over this opt out
<jarhar> sbender: segment exists in safari
<jarhar> sorvell: safari focus is from another universe
<lwarlow> RESOLVED: Elements with tabindex="-1" participate in focusgroup navigation when focused
<sorvell> +1