Should menu shortcut keys be case-insensitive?

[dlockhart]

Watching @svanherk's GAAD demo today made me wonder if we shouldn't be treating the printable characters in menu items in a case sensitive way? It seemed really unintuitive to me to need to know whether a menu item is "Delete" vs. "delete" to know whether to hold down shift.

The spec is ambiguous:

Any key that corresponds to a printable character (Optional): Move focus to the next menu item in the current menu whose label begins with that printable character.

Thoughts?

[cbellini]

At first, I wasn't sure if the SHIFT key was pressed as a necessary modifier to the keyboard shortcut, or needed to match the text 🤔.

WebAIM is equally ambiguous:

You can also filter by typing letters, but this behavior varies by browser. Some will filter as you type, like autocomplete. Others will only sort by first letter. E.g., in a list of US States, hitting A then R may take you to Arizona, or it may take you to Alabama and then Rhode Island.

Case-insensitivity feels like a better experience (do screen readers indicate casing?) and matches the experience in other platforms (e.g. Windows Explorer/Finder), which reminds me of the Win32 guidelines.

[svanherk]

At first, I wasn't sure if the SHIFT key was pressed as a necessary modifier to the keyboard shortcut, or needed to match the text 🤔.

Yeah it was just to make sure the exact character code was passed in. If the menu items had started with lowercase letters I could have just pressed "t".

I made sure to point it out in the demo in case people went and tried it out after, because I found it un-intuitive and @dbatiste had to point out how to get it to work

[dbatiste]

Case insensitive seems reasonable to me.