[focusgroup] Add sections on scrolling and keyboard conflicts

[janewman]

Clarifies key conflict element behavior and adds documentation for scrolling interactions in the scoped focusgroup explainer.
This addresses how focusgroups handle interactive elements that consume arrow keys (like text inputs) and introduces an automatic tab-escape behavior for native elements with keyboard conflicts

Related issues:

• Key conflict element behaviors: [focusgroup] Default behaviour for key conflict elements #1281
• Scrolling interactions: Focusgroup: Declarative keyboard focus navigation for a scoped set of composite widgets whatwg/html#11641 (comment)

[css-meeting-bot]

The Open UI Community Group just discussed [focusgroup] Add sections on scrolling and keyboard conflicts.

The full IRC log of that discussion

<jarhar> Jacques1: ive got a couple prs out that update the explainer for focusgroup
<jarhar> Jacques1: the first one adds sections for scrollling behavior and keyboard conflights
<jarhar> Jacques1: ill start with keyboard conflicts
<jarhar> Jacques1: philip has brought up this concern like sarah was saying, youre in a focusgroup and theres a complex widget which also uses the same keys
<jarhar> Jacques1: a good beahvior or a sane default
<jarhar> Jacques1: lets say youve got this toolbar with a radio group in the same axis and its parcitipating in the focusgroup
<jarhar> Jacques1: because it conflicts with the keys in the focusgroup, it gets priority over the focusgroup
<jarhar> Jacques1: the issue then is that you cant exit with the arrow keys
<jarhar> Jacques1: and radios dont have a concept of existing
<jarhar> Jacques1: the solution is that when you hit tab, theres an escape mechanism which then brings you back into the parent focusgroup
<jarhar> Jacques1: it would be the next item or authors can control it with tabindex
<jarhar> Jacques1: we can have a sane default behavior, youre always moving in one direction, not skipping content
<masonf> q+
<jarhar> Jacques1: that allows these key conflict elements to behave as they do today
<jarhar> Jacques1: an input element or a contenteditable, you dont want these arrow keys to take on a new meaning just because youre at the end, and tab is the way that people are used to leaving these controls
<jarhar> masonf: i was hoping youd say tab so that makes sense to me. is there an established pattern from this or an expectation from at users? is there a right answer or are we guessing?
<jarhar> Jacques1: im guessing. i wouldnt mind putting it in front of at experts
<masonf> ack mason
<flackr> q+
<jarhar> Jacques1: if you do the default behavior, things work. a radio behaving like a radio and input like an input with tab to exit makes a lot of sense. most ats will follow the focus, and so tabbing out will get you out
<masonf> ack flackr
<jarhar> flackr: there was a similar conflict in spatial navigation. i think there, the decision was to go a different way which was when you move to something that had a more specific inner control, you had an explicit activation to enter that, and some other exit key
<jarhar> flackr: we dont have those as things, tab is the only button we have
<sarah6> q+
<jarhar> flackr: that is the prior art that comes to mind
<masonf> ack sarah
<jarhar> sarah6: for the having a key to enter and exit, thats something ive done 2 years of user studies on. we do that for our chat list, which is different but similar. you arrow among complex things, and we have an enter exit pattern, with esc key
<jarhar> sarah6: the user studies shows that nobody learns it and likes it
<jarhar> sarah6: ive had repeats who still dont remember it
<jarhar> sarah6: its rolled into actual products
<jarhar> sarah6: in theory, this would now be an even more learnable pattern, and they dont
<jarhar> sarah6: i dont know if its unlearnable, but it seems people are resistant to learning
<jarhar> sarah6: i like this idea of arrow keys and tab
<jarhar> sarah6: it should be treated as a fallback
<lwarlow> q+
<jarhar> sarah6: we are providing a way for people to get out of this
<jarhar> sarah6: even if the established pattern is not to do that
<jarhar> sarah6: dont put an input or a select in a toolbar
<jarhar> sarah6: if someone does something really cursed like a grid in a toolbar, they can make their own js to navigate it and leave it
<masonf> ack lwarlow
<jarhar> lwarlow: on the toolbar front, i know the apg guidelines and i assume the actual aria spec mentions that if you have an input, put it at the end of your toolbar and then its not the end of the world because youd use tab to get out of the toolbar anyway
<jarhar> lwarlow: theres already guidelines on doing that, and in browser devtools we can say that this should be at the end of your toolbar
<jarhar> lwarlow: as you say, theres potentially certain cases where we can do things other than this, but as a general rule i think this makes a lot of sense
<jarhar> lwarlow: the interesting case of vertical toolbar with select, i could imagine a world where the toolbar orientation is vertical, that somehow inherits to the select such that the arrow key behavior is different. side arrows could open select
<jarhar> lwarlow: that doesnt help with radio buttons because radio buttons navigate regardles of which direction of arrow keys you use
<jarhar> lwarlow: there is a separate issue about an orientation attribute, maybe that could override
<jarhar> lwarlow: as an initial solution this sounds quite good
<jarhar> lwarlow: for more specific cases we could add other interventions
<jarhar> Jacques1: this behavior would only happen if the native element had a real conflict. if it doesnt use arrow keys its not going to matter, and if its the different direction then theres also no conflict
<masonf> q+
<jarhar> Jacques1: regarding activation, were only doing this for native elements. if the author has their own arrow key handling then its up to them to add behavior
<jarhar> Jacques1: as an author its recommended to have an activation key and then escape to exit. sarah if you think thats bad then you should comment
<keithamus> q+
<jarhar> sarah6: i dont think we should recommend it. you could arrow to an item and then put everything within it in the tab order tends to work better
<jarhar> sarah6: i dont think we necessarily need to tell authors how to handle that
<jarhar> masonf: can you put subitems of the focusgroup in the tab order?
<jarhar> sarah6: say you were using a focusgroup on the chat thing i mentioned. what you want is you arrow to a chat and then you add all the links and buttons in the taborder by manipulating tabindex. if you hit tab then it goes into that thing
<jarhar> sarah6: i think we should make sure focusgroup support that
<jarhar> Jacques1: it sounds like youre talking about you wouldnt want these buttons to be in the focusgroup, like a child focusgroup
<jarhar> sarah6: i need to look a the proposal again to see how you would do this
<jarhar> Jacques1: i think the proposal would account for that, but open an issue if you need
<jarhar> masonf: which controls have keyboard behavior is different across platforms and browsers. does that matter? it might not be predictable
<jarhar> Jacques1: its an issue in that as you mentioned wpts are going to be impossible to write for those scenarios
<jarhar> Jacques1: the idea that each UA needs to provide a single standard escape mechanism
<jarhar> Jacques1: thats an understandable requirement
<masonf> ack mason
<masonf> ack keith
<lwarlow> q+
<jarhar> keithamus: custom elements and scripts and things, can they declare a way to participate in this behavior?
<jarhar> keithamus: maybe we could provide something slightly better, if you add this attribute then tab will skip over content in this group
<jarhar> Jacques1: im hesitant to add more scope creep
<jarhar> Jacques1: i think right now, my feelings, if you as an author youre doing something interesting with arrow keys, and consuming this and stopping the browserd eefault behavior from working, its on you as the author to provide a way to leave your control
<jarhar> Jacques1: maybe i could be convinced to add a new attribute to get this behavior, but idk id push back on that right now
<jarhar> keithamus : thats reasonable
<jarhar> masonf: i lik ethe approach, if you can do it in js then just do it
<jarhar> masonf: but focusing the next thing in js is not simple
<jarhar> keithamus: we do have a proposal for focusnext
<sarah6> q+
<masonf> ack lwarlow
<jarhar> lwarlow: what happens when you have focusgroup none?
<jarhar> Jacques1: that means it is not particiapting in focusgroup
<jarhar> lwarlow: if im focused on an item on the focusgroup and it dybamically changes to focusgroup none, can i tab to get to the next item in the focsugroup?
<jarhar> Jacques1: yes
<jarhar> lwarlow: thats a solution to the problem?
<jarhar> Jacques1: the difference is the idea that focusgroups retain memory, and if youre in the focusgroup the memory is on you. when youre in the focusgroup you should go tothe element that has memory
<jarhar> Jacques1: if i was an author and i had a custom element ath uses arrow keys, the smart thing to do would be just say focusgroup none on that element and you have reasonable behavior without js
<jarhar> Jacques1: if you set it dynamically then that would work
<jarhar> Jacques1: if you wanted to avoid the code to find the next element, that would be a workaround
<masonf> ack sarah
<jarhar> Jacques1: i hadnt thought of that
<jarhar> sarah6: i was going to +1 letting authors write js for that
<jarhar> sarah6: this is all case by case custom behavior
<jarhar> sarah6: its premature to try to build something into focusgroup
<jarhar> sarah6: if something has changed outside the focusgroup and you want to change where focus goes to
<jarhar> Jacques1: all the author would need to do is update the tabindex and the focusgroup will update for them
<jarhar> Jacques1: i want to get to the second part of this pr about scrolling interactions
<jarhar> Jacques1: if you have a scrolling element in the focusgroup that is focusable, that would operate on the normal key conflight beahvior
<jarhar> Jacques1: if the scrolling behavior is in the same direction as the focusgroup, then you have to use tab to go to the nextitem in the focusgroup
<jarhar> Jacques1: in the example of the chat wehre everything in the chat is a focusgroup
<jarhar> Jacques1: we need to make the next element visible
<jarhar> Jacques1: you would scroll to make it visible
<bkardell> every single chat is a focus group?
<bkardell> ta
<nmn> q+
<jarhar> Jacques1: an open question would be if you hit arro wkey down and the next fodusable item is focusable, should we scroll the window
<bkardell> s/wehre everything in the chat is a focusgroup/where everything in the chat is a focusgroup item
<jarhar> Jacques1: that does bring in the issue of skipping content, but it allows focusgroup to be a way to skip to relevenat content
<flackr> q+
<masonf> ack nmn
<jarhar> nmn: i agree with the we should jump at least for now because thats what happens today with most scrollable divs
<jarhar> nmn: we would use tabs and jumps to scroll into view
<jarhar> nmn: as a separte solution for this problem we already have smooth scrolling css and it might make sense to enable that for focus based scrolling
<jarhar> nmn: thats something we could add separately from this proposal. for focusgroup i think jumping makes snse
<masonf> ack flackr
<jarhar> flackr: most of the time jumping makes sense. i thin kof this as being identical to mandatory scroll snapping.
<jarhar> flackr: pressing the arrow key will jump you to the nearest item. if its bigger than the viewport then it lets you scroll that before going to the next item
<jarhar> Jacques1: so if the next focus item is offscreen then we jump, but if its
<jarhar> flackr: if youre not at the edge of the ? then we continue to scroll to the focus item
<nmn> q+
<jarhar> Jacques1: iill need to clarify
<jarhar> flackr: you can try this with scroll snap areas
<keithamus> q+
<jarhar> Jacques1: would there be a difference between a big focus item or would it be the same behavior?
<jarhar> flackr: i propose that the content between, that would be a developer error
<masonf> ack nmn
<sorvell> q+
<Jacques1> or the chat example with a really long chat message
<jarhar> nmn: i think its still a little weird to do that. i dont think its a big concern because this is rare, but i could imagine cases where we have a small floating toolbar, and if it has text it doesn't fit. its weird that youre in a focusgroup and you press right to go to the next item and it just doesnt
<jarhar> nmn: icon with a long label, you can usually figure out what it is. if youre on a screenreader youd hear the whole thing anyway. so it might not be what you expect
<jarhar> flackr: the reason that i think its important to handle is this is the edge case that the developer wont notice because of different screen sizes
<jarhar> flackr: i dont know that i find it that surprising
<jarhar> Jacques1: i think this makes sense if theres large amount of content in between then its developer error
<lwarlow> q+
<jarhar> Jacques1: if theres a really long chat message, the user expectation is that you could scroll through it rther than jumping
<masonf> ack keith
<jarhar> keithamus: if these things are contentious, these are behaviors that could be customized with css. scroll snapping behavior and animation
<masonf> ack sorvell
<jarhar> sorvell: this is a hard thing. its a bad design. the weird case of a chat thing - why are chat things focusable?
<jarhar> sorvell: a long thing that doesn't fit on the screen being focusable seems tricky
<masonf> There are actions on the chat message, like "heart" it.
<jarhar> sorvell: we should do the simplest thing, just have the keys change the focus
<jarhar> sorvell: or as keith said it should be configurable, if this is an important case
<masonf> q+
<jarhar> sorvell: you cant say what the right answer is, unless its wrong
<jarhar> flackr: we also said that its wrong to put radios in a focusgroup, we are still making it accessible. not making it possible to navigate the content by keyboard is bad
<sarah6> q+
<jarhar> Jacques1: disocrd does this with arrow keys, seems like a common enough behaviorp
<masonf> ack lwarlow
<jarhar> lwarlow: i just wanted to say what rob said. i think its easy enough to say that something is devloper error. we do also need to handle that case.
<jarhar> lwarlow: if you have non focusable stuff in between its more cmoplicated. scrollers have more keyboard problems, like overflows quite bad there
<jarhar> lwarlow: if the next item is offscreen, maybe it scrolls the container until it comes onto screen, so you dont have that situation
<jarhar> lwarlow: we could probably easily put warnings in the browser
<jarhar> lwarlow: just skipping the focusable items would be problematic
<jarhar> q?
<keithamus> looks like discord also has a scroll margin effect, as the focus isn't at the very top of the page.
<jarhar> masonf: discord has interesting behavior. each individual message isnt tab focusable, but is only accessible with arrow keys
<lwarlow> q+
<jarhar> masonf: its like a user intervention, its probably good to have the arrow keys scroll
<jarhar> masonf: im afraid of making it configurable because thats a footgun
<keithamus> q+
<jarhar> masonf: if its the right thing to do to scroll with the arrow keys, we should just make it do that
<masonf> ack mason
<jarhar> flackr: i tested and discord does scroll for large messages
<jarhar> Jacques1: when you say it scrolls you mean it jumps?
<jarhar> flackr: if a message is too big it does not go to the next message
<jarhar> sorvell: i got the opposite behavior
<jarhar> Jacques1: i go the same behavior as steve
<jarhar> flackr: maybe im mistaken
<jarhar> Jacques1: how about content in between we jump over, but content within the focusgroup is not on screen then we will scroll until the bottom is on screen
<masonf> +1
<jarhar> Jacques1: i think jumping around quickly is good and i dont think we should lock ourselves in to not jump around
<masonf> ack sarah
<sorvell> q+
<flackr> +1 to allowing skipping content between focusable items
<jarhar> sarah6: the suggestion is, when you arrow to an item thats off screen, it scrolls the page instead?
<jarhar> Jacques1: yes but theres 2 ways this can happen
<jarhar> Jacques1: theres content thats in between the items thats not part of the focus group, or an item itself is too big
<jarhar> sarah6: i think we shouldn't disrupt the keyboard behavior of the focusgroup
<jarhar> sarah6: its normal to jump a massive amount
<jarhar> sarah6: i get that focusgroup is different beccause of arrow keys
<jarhar> sarah6: if youre a dev making this chat, and youre making things that youre arrowing around that big, then you should be able to move focus into them
<jarhar> sarah6: i dont think we should hijack arrow keys
<jarhar> sarah6: i havent seen that pattern anywhere
<jarhar> sarah6: we discussed this in the chat we made, you can move focus into that message
<sorvell> what about an alternate keyboard scroll afforandance?
<jarhar> Jacques1: thats the pr as written, im ok with it
<jarhar> masonf: what if i have a focusgroup that contains chat message, each message is focusable
<jarhar> masonf: the arrow keys are the only way i can see the message
<jarhar> sarah6: we let you move focus into messages
<jarhar> sarah6: i generally think thats good for message, but thats on the developer
<keithamus> q?
<jarhar> sarah6: if we move on to the design of focusgroup, then yes i would start to talk about that behavior and ask more questions about the type of chat youre making
<jarhar> sarah6: for that reason that its so specific to what youre building
<jarhar> sarah6: i dont think focusgroup should make things stop scrolling
<jarhar> flackr: but it does for radio groups
<jarhar> flackr: if an overly large thing is an edge case, then we should have a sensible default if they havent handled it
<jarhar> sarah6: when you throw a radio group in, the author has distrupted focusgroup
<jarhar> sarah6: when you throw an overly large item in, keyboard scroll kind of sucks
<jarhar> sarah6: i dont think we should make it harder for keyboard scroll to work, but it is a worse thing to make focusgroup arrows stop working
<jarhar> flackr: as a strawman alternative, we could only do this if theres not another focusable item within. for your case it has a focusable item within. otherwise they get the keyboard scrolling
<jarhar> sarah6: our focusable item only becomes focusable when you focus it
<jarhar> flackr: in radiogroups, you start moving within the radio group rather than the focusg roup
<jarhar> sorvell: if a radio button it will scroll?
<jarhar> keithamus: i think we should move on
<masonf> q?
<masonf> ack lwarlow
<jarhar> lwarlow: i still lean that there is an intervention that we should account for. maybe having long text between the items isnt worth handling because its not a common case enough, and would cause some disruption
<jarhar> lwarlow: if im on a focusgroup item thats going out of the page, and i press the key and it goes to the next item thats fine
<jarhar> lwarlow: we may change this to make it better
<sarah6> q+
<masonf> I'll say this in chat, to save time: Chromium currently makes scrollers focusable themselves, only if there aren't contained focusable elements. This feels very similar. So I like Rob's suggestion to maybe only do the special scroll thing if the focusable item doesn't itself contain something focusable.
<jarhar> lwarlow: it would be unfortunate if we regress on that if there is alternative behavior
<jarhar> lwarlow: if youve just got a set of radio buttons, we should see what do browsers do here
<jarhar> lwarlow: browsers are a focusgroup
<jarhar> sorvell: as far as i can tell radio buttons that dont fit on the screen dont scroll
<jarhar> lwarlow: maybe thats an example of why keyboard navigation is bad on the web
<jarhar> lwarlow: you could look at it either way
<jarhar> lwarlow: that and listbox, we can take some precedent there
<jarhar> lwarlow: maybe we could see if people are running into real issues
<jarhar> lwarlow: i could imagine once this is defined, we can define some of those other items on this
<keithamus> q-
<masonf> I would imagine this particular behavior can be adjusted later, if it's wrong initially...
<jarhar> lwarlow: even if just as a non normative this is how you should do it
<jarhar> lwarlow: it would be nice if listboxes use this kind of focusgroup, and then all of these sort of things would automatically be handled
<jarhar> sarah6: the reason im opposed to it, if theres a screenreader and it scrolls then it will be silent then it will seem broken
<flackr> that's a good reason
<jarhar> im going to stop scribing now before i get blisters on my fingers
<lwarlow> Okay we should make screen readers behaviour better
<lwarlow> So I'm sold
<keithamus> Zakim, make minutes
<Zakim> I don't understand 'make minutes', keithamus
<keithamus> Zakim, please end the meeting

[sorvell]

Here's a little example to help evaluate related behavior of native elements.

Chrome and Firefox activate and scroll to the focused/selected radio when arrow keys are used, Safari activates it but does not scroll to it (but it does scroll to the item focused by the tab key, seems sort of inconsistent).

Segmenting the radio group with focusable elements works mostly as proposed in the explainer but the segments without an active radio cannot be focused with tab, effectively changing the focus order when the selected radio changes.