Keyboard behaviour of custom select options

[o-t-w]

In Safari all the arrow keys work to move focus. In Chrome only the up and down buttons work.

The layout of the options of a custom select may be horizontal, vertical, or in a grid. When the layout is not vertical, the behaviour in Chrome is problematic because the up/down keys have to be used to move left and right. When the options have a grid layout, neither the Chrome nor Safari behaviour is ideal.

[josepharhar]

Thanks for the feedback! We could make right arrow and down arrow always go forward, and make left and up always go backward. That is what safari is doing, right?

As for grid, there was a related issue here: #1229

It kind of sounds like spatial navigation is what people want for that? I wonder if spatial navigation with arrow keys has any other use cases besides select or had any other proposals to actually be web exposed

[scottaohara]

2-dimensional/spacial navigation would definitely need some sort of a11y api mapping so that screen readers could communicate the fact the listbox no longer behaves like other listboxes. Or, maybe it could somehow be re-mapped as a grid.... that would at least communicate the 2d layout./ keyboarding expectations,.. though imo it'd be better to just make that (grid) a type of supported popup, rather than have the a11y mappings change based on styling choices

[lukewarlow]

The other proposals would essentially be 3d focus groups which is definitely something we want but is also something that needs more thoughts.

[gregwhitworth]

Looping in the ARIA group

[josepharhar]

Or, maybe it could somehow be re-mapped as a grid.... that would at least communicate the 2d layout./ keyboarding expectations,.. though imo it'd be better to just make that (grid) a type of supported popup, rather than have the a11y mappings change based on styling choices

Grid could be a whole separate primtive that we make a new html element for, right? I'm not super familiar with grids, but maybe that would be a good path to go down to support this somehow?

I think that for now we should decide on whether the left/right arrows should go back/forward or not in horizontal-tb, and whether up/down should go back/forward in vertical writing modes, which is what safari is doing based on my reading of the OP.

[brechtDR]

So... there are a few things to consider here. When (certain) people go wild with styling, there are a few things that can happen. I'd like to add a bit more info.

Here I have a multi-select, a grid would make sense here in some level:
https://codepen.io/utilitybend/pen/xbOOayg

However, since we are in a select, I don't find this particularity needed. I'll leave this open to the group, but wanted to highlight an example.

But the left and right buttons can have some downsides:
https://codepen.io/utilitybend/pen/poMpNbg

In this demo, I added a horizontal scroller with scroll snapping. I noticed this demo did not work on Safari, which is a shame. I know this is already highly customized and a gamified experience (which you shouldn't use on a regular website, but maybe for a browser game?)

Still, it feels like it's fighting with potential examples, and it should be specified whether these arrows do something, or not, and preferably be the same across each browser.

[css-meeting-bot]

The Open UI Community Group just discussed Keyboard behaviour of custom select options.

The full IRC log of that discussion

<lwarlow> q+
<keithamus> jarhar: there are two issues here; 1. should chrome implement the safari behavior, where right = down and left = up. 2nd issue is how do you make this work nicely in grid.
<keithamus> jarhar: should have double checked safari's right=down/left=up
<keithamus> jarhar: maybe we can resolve on that?
<dbaron> My inclination is that maybe you want the default behavior of the different arrows to depend on direction and writing-mode
<keithamus> jarhar: appearance:auto right and left don't do anything... though maybe in vertical writing mode?
<gregwhitworth> q?
<keithamus> ack bkardell
<keithamus> lwarlow: safari behavior is right same as down and left is up; essentially focusgroup where axes is both
<keithamus> lwarlow: on topic of focusgroup, ??? listbox constrained. This is a listbox.
<keithamus> lwarlow: ultimately i think keyboard stuff is impl defined, so fine either way
<gregwhitworth> q+
<keithamus> lwarlow: we need to solve problem of what you do when styles change layout; need to solve for focusgroup and select. A larger thing to do rather than take an action on select specifically.
<keithamus> lwarlow: from my perspective: chromium doesn't need to change immediately, more research on 2d focusgroup and grid focusgroup
<keithamus> lwarlow: maybe a way to apply that to select. Maybe solution is to add focusgroup to select.
<Jacques> I'll be spending time on 2D focusgroup immenently.
<keithamus> gregwhitworth: agree with your proposal, completely disagree on listbox being vertical
<keithamus> gregwhitworth: I like the examples posted - like a game, but select, but horitonzal, left/right makes complete sense to do
<keithamus> gregwhitworth: simple, all directions make sense.
<keithamus> gregwhitworth: figuring it out holistically, with a bunch of demos
<keithamus> dbaron: one other thought: intuition for i18n is possibly that- ignoring potentially dealing with 2d better- it makes sense to have defaults for which arrows do what be a function of writing mode, e.g horitontal rtl vs vertical rl
<keithamus> lwarlow: something we want to check with i18n people. Discussed for focusgroup, visual doesn't mean it impacts directionality of keys
<keithamus> dbaron: seems most weird for vertical rl
<keithamus> dbaron: select by default starts at right with each option to left, seems weird for left and right to do the opposite of that.
<keithamus> jarhar: left goes forwards and right goes backwards - so different between writing modes, want to post on the issue to highlight exact browser differences
<keithamus> ack dbaron
<gregwhitworth> ack gregwhitworth
<bkardell> resolved: there will be no resolution
<bkardell> good job everybody
<bkardell> 🍻
<keithamus> Zakim: end meeting
<keithamus> Zakim, end meting
<Zakim> I don't understand 'end meting', keithamus
<keithamus> Zakim, please leave
<Zakim> leaving. As of this point the attendees have been dbaron, gregwhitworth, sarah, flackr, vmpstr, bkardell, lwarlow
<keithamus> RRSAgent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2026/07/09-openui-minutes.html keithamus
<keithamus> dbaron: do you happen to recall how I can get github-bot to post on the last issue?
<keithamus> I forget the invocation required

[josepharhar]

Here's a demo which shows the different keyboard behavior we implemented:

<style>
select, ::picker(select) {
  appearance: base-select;
}
</style>

<select>
  <option>one</option>
  <option>two</option>
  <option>three</option>
</select>

<select style="writing-mode:vertical-lr">
  <option>one</option>
  <option>two</option>
  <option>three</option>
</select>

<select style="writing-mode:vertical-rl">
  <option>one</option>
  <option>two</option>
  <option>three</option>
</select>

Putting the behaviors in a table feels hard so I'll just say it:

• For vertical-lr, chrome and safari do the same thing: left and up arrow keys go backwards, right and down arrow keys go forwards.
• For vertical-rl, chrome and safari do the same thing: right and up arrow keys go backwards, left and down arrow keys go forwards.
• For horizontal-tb, chrome and safari are different:
  • chrome: up arrow goes backwards, down arrow goes forwards. left and right keys do nothing.
  • safari: left and up arrows go backwards, right and down arrows go forwards. same as vertical-lr.

I implemented the chrome behavior to simply match the safari behavior which they put in a wpt here, which must have not tested right/left in horizontal-tb: web-platform-tests/wpt@d2ad58e