useHotkeys inaccurately infers characters, breaking alternate layouts, hurting accessibility and localisation

[ollie299792458]

Environment

• Package version(s): >=5.0.2
• Operating System: All
• Browser name and version: All

Code Sandbox

Link to a minimal repro: https://blueprintjs.com/docs/#core/hooks/use-hotkeys (the keyboard)

Steps to reproduce

1. Set your keyboard layout such that it doesn't match your physical keyboard layout
2. Try to use the piano with a key where both the physical key and the mapped character appear on the piano
3. The key based on the physical key value lights up, not based on the mapped character

Actual behavior

useHotkeys makes use of code to infer which character a user has pressed, Mozilla's documentation states this is not correct usage: "Be aware, however, that you can't use the value reported by KeyboardEvent.code to determine the character generated by the keystroke".

Currently users with keyboard layouts that don't match their physical keyboard are unable to use hotkeys effectively, as hotkeys will often end up colliding with browser shortcuts. For example, if an application has a cmd+b hotkey a user of Left-handed DVORAK wouldn't be able to use cmd+w to quit the tab, and would instead end up triggered the cmd+b hotkey.

This has localisation impact (French user typing in AZERTY on a US keyboard) and accessibility impact (one handed user typing using a one handed DVORAK layout).

Expected behavior

key should be used when the character generated instead of the specific key position is desired. This way the users keyboard layout is respected, this is the approach shared by most software, websites, and operating systems, the main exceptions are some video games (but most support in application key remapping of some form)

Possible solution

The issues with useHotkeys raised in #6257 would return if a simple switch back to key was done. However, from my research, key combinations using option/alt are reasonably rare in web applications. Additionally, alt key combinations risk conflicting with users wanting to use alt codes to type special characters, so maybe we should consider not supporting alt based combinations.

Some nuance is likely needed with handling modifier keys, thoughts here:

• Use getModifierState to handle a few common modifier keys
• Find an appropriately licensed hotkey library to incorporate that deals with this issue already.
• The experimental getLayoutMap could be used
• Hard part will likely be ensuring it isn't a breaking change for those with keyboard layouts that match their keyboards