Selection in Menus should wrap based on platform norms

[carmacleod]

Interestingly, native menus wrap selection on Windows, and they don't wrap on Mac. By "wrap" I mean that if the user keeps typing down arrow [up arrow], they will eventually wrap to the top [bottom] menu item and continue selecting from there.

It would be nice to special-case whether or not to wrap Carbon menus (including context menu and overflow menu) based on the platform, and the behavior needs to be consistent across components.

Combobox wraps, Dropdown doesn't, OverflowMenu wraps, ContextMenu doesn't.

Need a proper inventory of components (instead of just my 2-second test ;) and need to be sure how the equivalent platform components behave by testing more thoroughly before deciding how to proceed.

I couldn't decide whether to open this as a bug or an enhancement, but I decided on bug, because as a Windows keyboard user, the context menu not wrapping felt really wrong to me.

[emyarod]

in the case of dropdown I believe it's also mimicking Select so that's why it currently does not wrap. should we tackle this on a component by component basis or should we adopt the existing platform behaviors?

[carmacleod]

Question: Do people use Carbon Dropdown for menus? If so, that complicates things.

Personally, I would tackle all of the menu-related components first, and make them match the platform's menu wrapping behavior.

Then look at the dropdowny/comboboxy/select-like components on a case by case basis. Maybe they are ok? There was some inconsistency - maybe that should be looked at? What do the platforms do?

Mostly, I care about the menu behavior. I only mentioned combobox/dropdown because @janhassel asked about dropdowns, which at first I thought meant "dropdown menus". Still not sure what was meant... ;)

[janhassel]

@carmacleod No, Dropdowns shouldn't be used for menus I think. I only brought that up because of the similar interaction (list of clickable elements), maybe that was a bad reference.

I agree, we should try to follow the respective system's behaviour for the individual components. Do you have a list of what native components wrap on which system and which don't?

[carmacleod]

Do you have a list of what native components wrap on which system and which don't?

Not really. I only really noticed that menus (including context menus) wrap on Windows (I'm mostly a Windows user).
Then I checked Mac and saw (to my surprise) that menus (and context menus) don't wrap there.

---

Regarding other popup-listy things, looking in Settings - General on Mac, native pop-up buttons don't wrap.
I only found one (native?) combobox, in Pages, File -> Export, EPUB, Advanced Options, Category. Doesn't wrap.

Looking through Settings on Windows, there are lots of "read-only comboboxes" (really similar to Mac pop-up buttons) that don't wrap, although there are similar things in Word that do wrap (in File -> Print, for example), and hilariously, in the Word ribbon, Font and Font size don't wrap, but Find, Replace, and Select do wrap. In File Explorer, New item and Easy access both wrap.
I found a combobox in Notepad, File -> Open... File name:. That one wraps. So does the search in File Explorer.

---

We could also look at HTML datalist and select, to see if they behave the same in each browser.
And HTML context menu, but note that it's deprecated, so not necessarily useful data.

macOS

HTML	Chrome	Edge	Firefox	Safari
datalist	wraps	wraps	wraps oddly	wraps
select	doesn't wrap	doesn't wrap	doesn't wrap	doesn't wrap
menu	doesn't wrap	wraps	doesn't wrap	doesn't wrap

Windows

HTML	Chrome	Edge	Firefox	IE
datalist	wraps	wraps	wraps oddly	doesn't wrap
select	doesn't wrap	doesn't wrap	doesn't wrap	doesn't wrap
menu	wraps	wraps	wraps	wraps

So the data for popup-listy things seems somewhat inconclusive - it's even app-specific in some cases. :)
For menus, though, it's pretty clear: make menus wrap on Windows, and not wrap on Mac. :)

[mbgower]

@janhassel asked me to have a look at this, after my comments on the behaviour in the combo-button and menu button.

First, it is always a bittersweet experience coming across these issues created by Caro, now no longer with us. I continue to be awed by how far-ranging her knowledge in the field was. Her summary above is predictably astute. The one qualifier I will throw in is that Mac as a platform for keyboard not only is not my favourite, but changes based on a fundamental OS setting! You are either given a default operating system where many things are not accomplishable with a keyboard or have to activate their special Full Keyboard Access mode, where TOO MUCH changes.

I double-checked just to make sure menus didn't wrap with full keyboard access mode enabled (they don't).

Further to my comments in the other thread, I think menu-like constructs in HTML (whether button menu or menu) should generally wrap. The ARIA example wraps in browsers on both OSes (even though on a Mac without full keyboard you can't even reach the menu button itself by keyboard on Safari; once you activate it by mouse, its items wrap by arrow key). So while native menus on a Mac are an exception, the HTML implementations seem pretty consistent.

As I said to Jan, there's no good reason for them not to wrap I can think of, and definite benefit.

A word about the native HTML Select element. They don't wrap anywhere. But they also have a lot of navigation methods not always available in a 'menu' (jumping by first key, reorienting to a match for a quickly typed string) many of which do 'wrap'. For instance, if you keep repeating S (with a slight pause each time) you will cycle through all the options in the select beginning with S and then wrap around to the first item again.

Since it's native, we obviously don't need to intervene here. But what about Carbon's dropdown? What about the Combobox?

These tend to lack a lot of the navigation options of the native select, so I think it's defensible to allow them to wrap. But I emphasize that I don't think either implementation will lead to risk to IBM as a violation of accessibility.