I've removed
“PageUp/PageDown, for jumping down many items at a time (how many? 10? jump to the first item that's just beyond view?)” from the task description as this would suppose that an assistive technology user already knows what options are available in order to jump over them. In my opinion not a real-world use case.

I have started to investigate this and I have a question on one of the point:

Allow the user to type characters and jump to the first item whose label/value matches those characters
We currently do this, but we filter just by label (or value) depending which on is displayed in the dropdown! Shall we change this approach?

We may want to create another ticket specifically for select elements as they are currently not filtering, but it has nothing to do with menu.

Home/End, for navigating to the first/last item
Currently when using "up" and "down" arrow while the menu is closed, it just open the menu but it does not select and item.

What shall we do in the case of "home" and "end", shall we follow the same approach?

Just to provide more context:

Quick video explaining the points:

• https://www.loom.com/share/d69fd9e0130b447982dfefda7e1c0ce0?focus_title=1&muted=1&from_recorder=1

Link of the select button from Mozilla link:

• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select

@SimoneThisDot updated keyboard shortcuts table in the menu component spec sheet, updating the following:

• arrow-up and arrow-down can open and close the menu and they won't have a looping behavior but they will navigate from the start to the end and viceversa (like in this video from mozilla).
• The user will be able to select an option with both enter and ctrl + space
• space will open and close the menu
• If the user types characters in the component that contains a menu, it will jump to the first item whose label or value matches those characters.

As the menu is part of other components, this keyboard navigation will be implemented the same in those components where the menu is displayed:

• Combobox
• Select
• Lookup

@bmartinezcalvo what about the use of the "home" and "end" buttons on the keyboard? This is from the aria website and part of the ticket created by Roan:

In T310556#8060783, @SimoneThisDot wrote:

@bmartinezcalvo what about the use of the "home" and "end" buttons on the keyboard? This is from the aria website and part of the ticket created by Roan:

Sorry @SimoneThisDot, added these keys too in the navigation table.

we should change the description of the ticket to include the following AC. @Volker_E calling you in so that you are aware of some of the changes that this will result in:

• Allow the user to type characters and jump to the first item whose label/value matches those characters (this just needs to be implemented in the select component. Other components already have this feature)
• Change behaviour to "open" and "close" the menu when clicking the space button but without selecting the currently highlighted item
• Add the ability to select an item by clicking space + CTR
• Change the current functionality to make sure we do NOT loop around when clicking up or down

Change 812081 had a related patch set uploaded (by Simone Cuomo; author: Simone Cuomo):

[design/codex@main] Menu: Improve keyboard support

https://gerrit.wikimedia.org/r/812081

In T310556#8061706, @SimoneThisDot wrote:

we should change the description of the ticket to include the following AC. @Volker_E calling you in so that you are aware of some of the changes that this will result in:

• Allow the user to type characters and jump to the first item whose label/value matches those characters (this just needs to be implemented in the select component. Other components already have this feature)
• Change behaviour to "open" and "close" the menu when clicking the space button but without selecting the currently highlighted item
• Add the ability to select an item by clicking space + CTR
• Change the current functionality to make sure we do NOT loop around when clicking up or down

Added this AC checklist in the task description. About the last one related with the loop behavior, should we remove the loop when the menu has many options? It helps the user to move within the options without having to go all the way back.

I have no personal preferences, so I would either leave it as it is (as we have no strong preferences) or we would have to involve the rest of the team (@Catrope @AnneT ).

1. jump to first item:

Yes, it makes sense to open

In T310556#8061706, @SimoneThisDot wrote:

we should change the description of the ticket to include the following AC. @Volker_E calling you in so that you are aware of some of the changes that this will result in:

• Allow the user to type characters and jump to the first item whose label/value matches those characters (this just needs to be implemented in the select component. Other components already have this feature)
• Change behaviour to "open" and "close" the menu when clicking the Space button but without selecting the currently highlighted item
• Add the ability to select an item by clicking Space + ⌃
• Change the current functionality to make sure we do NOT loop around when clicking ↑ or ↓

This all sounds right to me.
One small detail, the behaviour of a native select on Space is different here per browser. While in Chrome you can open the menu and select via Space, Firefox let's only open the menu. Closing is limited to ⏎ (Enter). I personally prefer ⏎ and ⎋ (Escape) as the “executing” keys and not adding Space to the selecting one.

Change 812081 merged by jenkins-bot:

[design/codex@main] Menu: Add Home/End keyboard button support

https://gerrit.wikimedia.org/r/812081

One thing that's been bothering me while testing TypeaheadSearch (which is an input + menu): Shift+Home and Shift+End don't work for selecting text, because the Home/End key presses are intercepted and directed to the menu instead. I suggest that we make the following changes:

• Home/End should not be intercepted when Shift is also pressed (i.e. Shift+Home should be allowed do its regular selection behavior, rather than navigating in the menu)
• Home/End should not be intercepted when the menu is closed (there's no menu navigation to be done in that case, so instead they should perform their regular function of moving the cursor to the start/end of the input)