Arrow key up/down on closed <selectmenu>

[dandclark]

Another <selectmenu> behavior to discuss: what should happen when the control's listbox is closed, and a user arrow keys up/down on the control's button?

Per my testing of <select> in Chromium and Gecko on Windows, up/down arrow keys advance backwards/forwards through the list of options without opening the listbox.

However looking at the example at https://www.w3.org/TR/wai-aria-practices/examples/listbox/listbox-collapsible.html, up/down arrow open the listbox in addition to moving to the next previous option.

Down Arrow

• Moves focus to and selects the next option.
• If the listbox is collapsed, also expands the list.

Up Arrow

• Moves focus to and selects the previous option.
• If the listbox is collapsed, also expands the list.

The guidance in https://www.w3.org/TR/wai-aria-practices/#listbox_kbd_interaction doesn't state that up/down arrow should open the listbox.

Down Arrow: Moves focus to the next option. Optionally, in a single-select listbox, selection may also move with focus.
Up Arrow: Moves focus to the previous option. Optionally, in a single-select listbox, selection may also move with focus.

So I'm not clear on whether the best practice is to open the listbox or not when up/down arrow is pressed. Thoughts?

(Thanks @mfreed7 for pointing this out).

[scottaohara]

I'm glad you opened this @dandclark, as I was reading through #386 and noticed this hadn't been mentioned yet.

The APG isn't going to be what can be looked at here for the definitive behavior since the select behaves differently depending on the platform, and the APG pattern takes a bit of both, though leaning a bit more towards macOS behavior. On macOS, the listbox always popsup when using the up or down arrow keys. Firefox on macOS allows for left and right arrows to cycle through the select's options when in the collapsed state. Safari and Chromium don't seem to behave that way, though.

On Windows, the expectation is that up, down, left and right will cycle through the select element's options without opening the listbox (firefox, chrome, edge). To open the listbox with arrow keys, someone would also need to use the alt key, along with up or down to get the listbox to popup.

Per the discussion the other day about #429, these differences in the listbox popping up or not matter a bit less since the change event will fire the same either way.

I'd imagine that preference for behavior may be contingent on people's familiarity with their primary OS.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[josepharhar]

https://w3c.github.io/aria-practices/#combobox-keyboard-interaction says a few things about up and down:

Down Arrow: If the popup is available, moves focus into the popup:

• If the autocomplete behavior automatically selected a suggestion before Down Arrow was pressed, focus is placed on the suggestion following the automatically selected suggestion.
• Otherwise, places focus on the first focusable element in the popup.

Up Arrow (Optional): If the popup is available, places focus on the last focusable element in the popup.

I don't understand what it means by "if the popup is available" though. Does that mean if the popup listbox is showing? Does it have something to do with the combobox being editable? Is it about the autocomplete suggestion rather than the actual listbox? I'm going to assume it means what the example does:

The example opens the listbox popup when pressing up or down, and it doesn't change the option at all. I'm a little hesitant to do this since it doesn't seem to be the same as what <select> does on most platforms, but if that's whats best for users then I guess we ought to go for it. Based on the resolution here, it sounds like we already have consensus to just follow these aria authoring practices.

I also just noticed that there is no recommendation for right or left arrow keys in the aria authoring practices... maybe those should cycle the selected option without opening the listbox like Scott mentioned in his last comment?

[josepharhar]

I tested out the behavior on various platforms and browsers:

• Up and Left choose the previous option, Down and Right choose the next option. The listbox is not opened.
  • Windows Chrome
  • Windows Firefox
  • Linux Chrome
  • Linux Firefox
• The listbox is opened. The selected option is focused but not moved forwards/backwards. Left and Right do nothing.
  • MacOS Chrome
  • MacOS Safari
  • MacOS Firefox

As scott mentioned, the behavior is platform specific and not browser specific, and users may expect it to act the way the existing select element does on their OS.

As I mentioned in my last comment, the ARIA practices seem to suggest doing the MacOS behavior but with an added funny behavior where pressing down opens the listbox and selects the last option.

My proposed resolution is to do the same thing that the existing select element does and change the behavior based on the OS because that is most likely to be what the user expects, but I am open to suggestions.

[css-meeting-bot]

The Open UI Community Group just discussed Arrow key up/down on closed.

The full IRC log of that discussion

<gregwhitworth> Topic: Arrow key up/down on closed
<gregwhitworth> github: https://github.com//issues/433
<gregwhitworth> q?
<hdv> jarhar: looking at the existing <select> the keyboard behavior is different between OSes
<masonf> q?
<masonf> q+
<jhey> Haha bkardell! :D
<hdv> jarhar: Scott said people might expect selectmenu to have the same differences in behaviors across OSes
<jhey> q+
<dbaron> jarhar: on Windows and Linux, Chrome and Firefox, up/left on a closed select moves to previous item, right/down moves to next item
<gregwhitworth> ack masonf
<dbaron> jarhar: on Mac (Chrome/Firefox/Safari), side arrows on a closed select do nothing and up/down arrows open it without changing the item
<hdv> masonf: I wonder what existing web frameworks do, when they build custom components?
<gregwhitworth> +10000000000000 to masonf
<hdv> masonf: I feel we should follow that behavior… I think we should build something that works the same everywhere, as what we're trying to do here or at least want to explore is to replace the existing behavior in people's design sytstems
<gregwhitworth> ack jhey
<gregwhitworth> q+
<hdv> bkardell_: you may be wrong in assuming behavior is the same across components in design systems
<hdv> jhey: before we talked about, I believe, how ENTER works, and then we picked the way Microsoft did it… should there be consistency in 'what we favour' ?
<masonf> q+
<hdv> jhey: the cyclical thing is popular, but some people might not want that
<bkardell_> q+
<hdv> gregwhitworth: we're definitely not favouring anything specific
<hdv> jhey: (was a hypothetical example)
<hdv> gregwhitworth: research should be done across the web, across design systems… user research should follow and then we should pick what would be the best solution
<hdv> gregwhitworth: whatever is best for the user
<hdv> gregwhitworth: I probably do agree that the majority of components that are authored in design systems, across web properties, eg like Salesforce, we're not going to provide for behavioral capabilities by doing a browser check and changing behavior based on the user's browser
<hdv> jhey: you're never going to please everyone… but maybe these behaviors could be exposed in attributes?
<hdv> jhey: I can see that people would try to customise this kind of thing
<gregwhitworth> ack masonf
<hdv> masonf: I don't think existing component libraries adapt to the platform they're used on , don't know of any
<hdv> masonf: what we should try and match is the majority of user expectations… not surprising them is the goal
<gregwhitworth> Facebook loops btw
<hdv> masonf: across the landscape of components and the web
<gregwhitworth> Twitter loops
<hdv> masonf: consistency is the most important… but the tricky bit is consistent with what, the web or OSes?
<flackr> q+
<gregwhitworth> github loops
<gregwhitworth> ack bkardell_
<flackr> q-
<hdv> masonf: don't feel great about attributes… because we don't want to surprise users, and attributes allowing developers to customise a lot would cause surprises
<gregwhitworth> q+
<hdv> bkardell_: not a lot of component libraries are like, 'this needs to work differently on Mac'… that's not a goal because it's a pain to do, nobody wants to deal with it
<hdv> bkardell_: Domenic has a poll… if we don't have to match expectation of the past and can do what we want, should we match platform or something new?
<hdv> bkardell_: obvious answer is it should work the same… but the poll got a lot of votes, feedback was almost 50/50
<hdv> bkardell_: people expect their operating system to work like their operating system. IF they're concious about it, which a lot of people are not
<flackr> q+
<hdv> bkardell_: there's also the question of how much research would be able to show here
<masonf> q?
<masonf> q+
<hdv> bkardell_: if we say 'it's this way, not like the way it works in Apple', we would need a standards position filed to find out if that would fly… to avoid people spending a year working on something that can't go anywhere. Not talking any specific vendor or person, just the nature of what we do
<hdv> gregwhitworth: 90% of the time I see a select it's a combobox… Facebook, Twitter and GitHub loop over… on the Mac I see differences between applications, not sure if Apple is even aligned everywhere
<hdv> gregwhitworth: every single site where you go to has different components and different behaviors
<hdv> gregwhitworth: there can be pushback in either direction depending on what the direction is
<hdv> gregwhitworth: so often it's about the specific methodology, not so much platform uniformity, may be a misnomer
<hdv> jhey: a lot of apps on Mac are Electron, web apps wrapped in a nice window
<gregwhitworth> ack gregwhitworth
<hdv> bkardell_: and even on the web, or in Electron apps, will work differently on the Mac
<hdv> bkardell_: an interesting perspective… if we want to look at PWAs etc, the argument curls up
<hdv> jhey: if you'd like to base it on what users expect… there's so much you can analyse… eg react select gets millions of downloads, and they do it this way
<masonf> q?
<hdv> bkardell_: if you look at our HTTPArchive markup analysis, we have seen a lot of reasons things are popular that are not necessarily they are good
<gregwhitworth> ack flackr
<hdv> flackr: I was going to make an argument for consistency with the platform
<gregwhitworth> q+
<hdv> flackr: we have a long precedent of… if you don't change the appearance of things ,they fit in with the platform. If they don't have a consistent behaviour on the platform that's different, but at least if you have, like, a scrollbar that would be the same as everty other scrollbar on the platform
<hdv> flackr: there's also differences between devices, eg a UI on the same OS could be different on a watch vs a phone vs desktop
<hdv> masonf: agreed, the spec can't really be absolute… eg in some cases there isn't a keyboard etc
<hdv> masonf: maybe we could go to a quick decision now and then when, say Apple, is able to join the conversation we would likely update it anyway
<hdv> gregwhitworth: they are not the plethora of form factors jumping out of the blue
<hdv> gregwhitworth: eg they might ultimately just map to pointer events
<jarhar> q+
<gregwhitworth> ack masonf
<gregwhitworth> ack gregwhitworth
<hdv> gregwhitworth: if there's an argument of going against existing, then I think about what Jhey was saying, developers should be enabled to make changes or otherwise use the default one
<hdv> flackr: it's harder to decide I want to make my controls look like native controls, vs I want to make these controls that normally look like native look different
<hdv> gregwhitworth: we already resolved that these elements are going to be interoperable by default. When you bring them in, they envision the “ugliest” selectmenu
<hdv> gregwhitworth: they just do the behaviours and look boring, then developers can go and style them how they need to be styled
<masonf> Here's the resolution: https://github.com//issues/536#issuecomment-1164737967
<hdv> gregwhitworth: if people's minds are changing about this we may have to revisit this
<hdv> gregwhitworth: there was talk re :native kind of toggles that allow folks to style as native
<hdv> flackr: I like the option of having something like appearance:native
<hdv> gregwhitworth: we talked about appearance:none to be the default
<hdv> q?
<gregwhitworth> ack jarhar
<hdv> jarhar: I am convinced by this conversation that we should have the same behavior across OSes and agree we should choose something and other browsers will look at it when it comes to ship it
<hdv> jarhar: I would propose we follow the macOS behavior for a couple of reasons
<masonf> q+
<hdv> jarhar: cycling through option without seeing the list is kind of confusing, seeing the list would be more clear for me personally, that's what I feel we should do
<gregwhitworth> ack masonf
<hdv> masonf: the only thing I've heard accessibility folks mention is when LEFT-RIGHT do nothing
<hdv> jarhar: sounds like a good extension to have ARROW LEFT RIGHT and ARROW TOP DOWN do the same thing
<hdv> gregwhitworth: going across a bunch of larger web properties, they all seem failry consistent in their cyclical behavior
<bkardell_> q+
<jarhar> Proposed resolution: Up, down, left, and right open the listbox without changing the selected option
<hdv> s/failry//
<gregwhitworth> ack bkardell_
<hdv> bkardell_: do we have folks from FAST, Material, Lightning, Adobe etc, and ping them/ask about this is what we are planning for behavior to be
<hdv> bkardell_: I expect roughly 50% would say one thing and 50% the opposite
<hdv> gregwhitworth: I can ping some folks like Chris Holt
<hdv> masonf: important to note that this behaviour could always be overridden by devs using event.preventDefault
<hdv> [ discussion on meaning of “interoperable” ]
<hdv> chrishtr: I feel we should resolve on 'unless there is a good reason not to, to ship with a default styling that is consistent across platforms', so that there is consistency for users that use different platforms
<masonf> +1
<hdv> chrishtr: may be hard especially with keyboard interactions
<hdv> gregwhitworth: kind of goes back to appearance:native… the hope would be… say one design system had a strong opinion on making a select work exactly like the platform, appearance:native would have both styling and behaviour
<gregwhitworth> q?
<hdv> [ gregwhitworth to create an issue for appearance native and for native cycle capability ]
<dbaron> BTW, I think the left/right doing the same as up/down means vertical writing modes all work isn't great -- I think it either (a) gets vertical CJK languages wrong or (b) assumes we'll never add support for vertical-lr scripts like Mongolian, Manchu, etc.
<jarhar> Proposed resolution: Up, down, left, and right open the listbox without changing the selected option
<bkardell_> dbaron: why?
<hdv> gregwhitworth: let's at the i18n label so that the horizontal i18n group at W3C can look at it
<hdv> s/at/add
<dbaron> bkardell_, for vertical Japanese/Chinese, I'd expect the first item in a select to be at the right and the later items to move left, whereas for Mongolian or Manchu script, I'd expect the reverse
<bkardell_> ah I get what you mean now... I don't think up down and left right as synonomous is affected by that though, is it?
<dbaron> bkardell, I think it depends what the up/down/left/right behavior is
<dbaron> bkardell_, if it's all "open the select" it's fine, if it's about moving between items then there may be issues
<hdv> masonf: important to note it is 'resolved for now' we will likely look at it again
<hdv> gregwhitworth: exactly
<bkardell_> ⬆️ ⬇️ : ⬅️ : ➡️
**RESOLVED:** Up, down, left, and right open the listbox without changing the selected option

[josepharhar]

We resolved to make up, down, left, and right open the listbox without changing the selected option.

[aphillips]

This issue got mirrored to I18N's repo due to the i18n-tracker label and I dug around to find the reason for the tag in the IRC log above:

[ gregwhitworth to create an issue for appearance native and for native cycle capability ]
BTW, I think the left/right doing the same as up/down means vertical writing modes all work isn't great -- I think it either (a) gets vertical CJK languages wrong or (b) assumes we'll never add support for vertical-lr scripts like Mongolian, Manchu, etc.
Proposed resolution: Up, down, left, and right open the listbox without changing the selected option
<bkardell_> dbaron: why?
gregwhitworth: let's at the i18n label so that the horizontal i18n group at W3C can look at it
s/at/add
bkardell_, for vertical Japanese/Chinese, I'd expect the first item in a select to be at the right and the later items to move left, whereas for Mongolian or Manchu script, I'd expect the reverse
<bkardell_> ah I get what you mean now... I don't think up down and left right as synonomous is affected by that though, is it?
bkardell, I think it depends what the up/down/left/right behavior is
bkardell_, if it's all "open the select" it's fine, if it's about moving between items then there may be issues
masonf: important to note it is 'resolved for now' we will likely look at it again
gregwhitworth: exactly
<bkardell_> ⬆️ ⬇️ : ⬅️ : ➡️

Just to confirm, arrow keys can signal either logical or physical movement, depending on context. Physical movement means "left is left and right is right (etc.)" regardless of text directionality or writing mode. Logical movement means that "left is towards the start (in an LTR context) vs. right is towards the start (in an RTL context)". Physical vs. logical movement depends on the operation in question.

List navigation should generally be logical rather than physical, with up being towards the start and down being towards the end. Left is "towards start" for LTR (dir=ltr) and vertical-lr modes and "towards end" for RTL (dir=rtl) and vertical-rl modes (with right mirroring the behavior).

Since you resolved to open the select (and not navigate), is there an equivalent issue somewhere about navigation? I don't see a reason here to reopen this issue.

[scottaohara]

since i could make the call, just commenting to clarify that while I had mentioned that people may have preferences, that for this topic that wasn't meant to indicate that I wouldn't also agree that cross-browser/platform consistency.

i actually think this is a good change.

however, because I"m me, i also wanted to respond to:

I wonder what existing web frameworks do, when they build custom components?

looking to design systems to mimic how they've implemented custom components like this would often mean a bunch of behaviors from the native equivalent were dropped. e.g., was left/right selection not implemented because of a purposeful choice, or because it wasn't ever thought about since the requirements were written by someone unfamiliar with the variations. Or, was it deemed too complex to implement? That often happens with custom select-only comboboxes in regards to the type ahead functionality. Most instances i come across don't allow for the quick jump to an option by pressing the first few characters of that option's label. For instance, neither Fluent UI or Salesforce comboboxes allow for this if using the select-only combobox. They also don't allow someone to click on their custom labels to move focus to the associated combobox element. That's not a dig on these, or anyone who worked on them. it's not "required" that they do these things. But they are missing features from what the current select element provide (or from what other custom made components may or may not provide compared to their native counterpart).

So, very long way of saying "yes, let's look at what other design systems are doing. BUT ALSO, let's look at what they didn't do compared to what they were trying to recreate. What did they leave out, and if something hit the cutting room floor, why?"

[mfreed7]

So, very long way of saying "yes, let's look at what other design systems are doing. BUT ALSO, let's look at what they didn't do compared to what they were trying to recreate. What did they leave out, and if something hit the cutting room floor, why?"

Totally agree! I just wanted to make sure we weren't limiting our research to native select menus. Really, I think everyone in this week's meeting seemed to agree that the right way to pick the "right" behavior was to consider what's best for users, and do that. As I said at the end of the meeting, I'm quite sure this issue isn't closed, it's just "closed for now". Please add your thoughts on what's best and we'll keep discussing.