[Range] Keyboard navigation for multi-handle ranges

[brechtDR]

Some first questions that come to mind

• How should users switch focus between multiple handles?
• What keyboard shortcuts should be used for handle selection and movement?
• How to ensure keyboard navigation remains accessible and intuitive?
• Should we support arrow key navigation between handles?

[sorvell]

How should users switch focus between multiple handles?

Tab

What keyboard shortcuts should be used for handle selection and movement?

Arrows

Should we support arrow key navigation between handles?

No. Arrows move handles, tab changes active handle.

Example that works this way from Angular Material.

[bkardell]

I guess worth mentioning that that probably comes from APG? https://www.w3.org/WAI/ARIA/apg/patterns/slider-multithumb/examples/slider-multithumb/

[css-meeting-bot]

The Open UI Community Group just discussed [Range] Keyboard navigation for multi-handle ranges, and agreed to the following:

• RESOLVED: Each tab stop goes on a thumb, keep current behavior as it is on the current input range for pagedown, -up, home, end.

The full IRC log of that discussion

<jarhar> brecht_dr: this might be a simple one, it might not be
<jarhar> brecht_dr: its about keyboard interactions we need in case you use a multi handle select (range?)
<jarhar> brecht_dr: how do you move the thumb
<jarhar> brecht_dr: currently most people think its a tab to get between the thumbs and use arrow keys to slide them
<jarhar> brecht_dr: second part of this question, is do we want to keep it like that?
<jarhar> brecht_dr: ive seen implementations where people use pageup and pagedown instead of just arrow keys for bigger steps
<jarhar> brecht_dr: for example, arrow down goes down by 1 and page down goes down by 10
<sorvell> q+
<jarhar> brecht_dr: is this common enough to be an accessibility feature?
<jarhar> brecht_dr: thoughts?
<jarhar> sorvell: so you started with how do you jump between the thumbs? you could use tab. then you moved on to you can move the thumbs with arrows and page down. how are those realated?
<scott> q+
<jarhar> sorvell: were discussing whether those are good or not, but are there alternatives?
<jarhar> brecht_dr: if there are 10 handles, do we want ways to skip around them? is this enough is kind of the question
<bkardell> q+
<masonf> ack sorvell
<jarhar> sorvell: im happy to talk about it more but i have not seen anyone with additional ideas
<jarhar> scott: i talked about this last time we brought it up. exactly what you were just saying brecht, there could be many
<jarhar> scott: maybe there is something better we could do than having someone tab through 10 tab stops for a single control
<jarhar> scott: i do kind of agree with steve that until theres a better proposal, they should all be in the tab order
<masonf> q+
<jarhar> scott: community feedback beyond this group would be good
<masonf> ack scott
<jarhar> scott: we could come up with something, its a single tab stop and someone needs to hit ctrl right arrow or control tab
<jarhar> scott: so its easier for people to keyboard past the whole thing
<jarhar> scott: but then how do you know that thing behaves that way
<jarhar> scott: thats always the problem when new keyboard behavior is suggested
<jarhar> scott: people need to learn, but if we make it easy so people dont need to learn thats also good
<jarhar> scott: lets resolve imo to just use tab key, unless community feedback can be found to say otherwise
<jarhar> scott: and maybe just say were gonna have this new tab key to bring in a11y nerds to say no this needs to be better
<jarhar> brecht_dr: thats not a bad idea
<masonf> ack bkardell
<jarhar> bkardell: i like invoking cunninghams law by saying the wrong thing to have someone say what the right thing is
<jarhar> bkardell: most of the implementations of this i imagine are in native toolkits
<jarhar> bkardell: im wondering if anyone has investigated how they work
<sorvell> q+
<jarhar> bkardell: i assume most of the web ones like most of the web things are just made by volunteers
<jarhar> bkardell: id be curious if there are implementations in qt or may be apple has a native one, how do they work
<jarhar> bkardell: has anyone looked into that?
<jarhar> brecht_dr: it is something that i did look prior to writing this, and if there is any behavior in those cases, its the one that i described first. just in the tab order, and arrow slide the thing
<jarhar> brecht_dr: some of them have pageup and pagedown idea as well for bigger jumps. that happens from time to time
<jarhar> brecht_dr: i dont know if thats a nice feature or a good idea
<flackr> q+
<scott> q+
<jarhar> bkardell: is there a catalog of this is the ones that are viewed and this is what they did, or a table or something?
<jarhar> brecht_dr: for the keyboard behavior, in detail not. but there are examples that can be found
<jarhar> masonf: if youve done the research, writing that down would be handy
<jarhar> masonf: it sounds like people agree that each thumb gets a tab stop
<jarhar> masonf: i wonder about arrow keys
<jarhar> masonf: for a horizontal sliders, should up and down arrows move that slider? or should it respect direction? im guessing that both should work
<masonf> ack mason
<masonf> ack sorvell
<bkardell> note many thumbs up in the meeting
<jarhar> sorvell: i think it should do the same thing range slider does, which is up and right arrow go to the right, down and left arrow go to the left for horizontal
<jarhar> sorvell: material and angular on the web, and zillow, they all did the same thing. tab stop for each thumb
<jarhar> sorvell: internally using range sliders, so they did the same thing with arrows
<jarhar> sorvell: my other question was, the skippable behavior, i know theres a proposal for focus groups. i dont know if that has this feature. if it does, maybe thats something that could speak to this more generally. any kind of groupable set of items could benefit from
<jarhar> sorvell: radio buttons dont work this way because they dont need to and they have the arrow keys to move between them
<jarhar> sorvell: if you had a group of checkboxes they might need this
<jarhar> masonf: you cant use focusgroup here because arrow keys already have meaning
<masonf> ack flackr
<jarhar> flackr: most AT ive used has a concept of entering and leaving groups, with frames and things, a frame is a single group you can enter. maybe AT could do something different if we thought that was a good patterN?
<jarhar> flackr: for keyboard controls, do the other stops serve as a point at which you cant cross? should pushing one marker push the other one? home and end might be reasonable to move to the smallest and largest value
<jarhar> masonf: lots of discussion on that last week, about thumbs on top of each other
<masonf> ack scott
<jarhar> scott: just to throw it out there, for the current range slider, right down goes up, left up goes down, home goes to start, end goes to end, pageup pagedown go up and down by step value
<jarhar> scott: if we are going to do something else, imo it should probably be with a modifier key
<jarhar> scott: lets reach out to community to see what they want
<masonf> flackr: https://github.com//issues/1184
<jarhar> scott: flackr brings up a good point about entering and exiting. on touch devices, swiping through one of these could be far more problematic than using the tab key
<jarhar> scott: maybe at could specifically allow someone to make a decision of whether they want to enter the range slider or just swipe past it
<jarhar> scott: could be something that we could maybe surface as a callout to consider for at
<jarhar> scott: on android, how would one interact with this where up and down volume is meant to make a thumb go back and forth. if theres five of them youd have to get to each of them individually
<jarhar> scott: flackr is correct, were going to need an at can enter thing concept
<jarhar> scott: that is probably separate from keyboard, at least for touch devices
<keithamus> q?
<jarhar> masonf: i heard agreement that each thumb should get a tab stop
<brecht_dr> Proposed resolution: Each tab stop goes on a thumb, keep current behavior as it is on the current input range for pagedown, -up, home, end.
<jarhar> brecht_dr: we can change this if people start yelling at us
<jarhar> masonf: behavior for home, i did hear agreement on arrow keys, not sure if we talked enough about home/end/pageup/pagedown
<jarhar> brecht_dr: i heard scott say that its currently that behavior, so we should keep it the same
<jarhar> masonf: if theres a common behavior, then thats great
<jarhar> flackr: the fact that we say this for tabs, that home and end go to the first and last tab, controls can and should take over home and end when they have meaningful things to do with them. if youre in an input box it takes your cursor to the beginning or end
<jarhar> flackr: im supportive of including it
<jarhar> masonf: good point, in all other form controls these behaviors aren't specified
<jarhar> masonf: customizable select
<jarhar> brecht_dr: should i leave it in or out?
<jarhar> masonf: put it in
<masonf> +1 to resolution
<sorvell> +1
<jarhar> keithamus: any opposed to the current proposed resolution?
<scott> +1
<bkardell> +1
<brecht_dr> RESOLVED: Each tab stop goes on a thumb, keep current behavior as it is on the current input range for pagedown, -up, home, end.