Summary

Several teams have implemented their own keyboard shortcuts for various bits of UI throughout Kibana. This, on top of the keyboard shortcuts that EUI ships, are bound to start conflicting at some point.

Managing discovery of keyboard shortcuts also poses a challenge that no one has yet undertaken nor have the accessibility issues of shipping arbitrary keyboard shortcuts been tackled.

Goal

Provide a way for Kibana teams and EUI components to register their keyboard shortcuts to improve discoverability and allow for a central management of them from both a developer and a user perspective.

Do people want this?

Not including issues of people complaining about our tab order not being what they want or expect (which strong keyboard shortcuts could help mitigate):

• Canvas a lot of keyboard shortcuts
  • Related issues: [Canvas] Refactor keyboard shortcut handlers #42628, [Accessibility][Layout Engine] Suggestion: Layer Selector #25505, Keyboard Shortcuts: Positioning and Manipulation of Elements #23058, [Layout Engine] Page Manipulation #23060, Ability to copy pages across workpads #32783, [Layout Engine] Keyboard Shortcuts for page navigation: Page Basic Commands #23057, [meta] Canvas accessibility #23534
• Console has some keyboard shortcuts
  • Related issues: Support disabling keyboard shortcuts in Console #48410
• Navigational Search has a very prominent shortcut
• Lens hopes to add keyboard shortcuts in the future
• EUI has several keyboard shortcuts in DataGrid and Selectable
• Ace our legacy in-browser text editor ships with its own shortcuts
• Monaco our next-gen text editor
• Long standing request for a general purpose action palette (Create a command palette with hotkeys for Kibana #15019)

Functionality & features

MVP

• A service for developers to register their keyboard shortcuts to
  • Can manage uniqueness: Critical on a per-page basis but also good to know across different pages
• A UI for users to view all shortcuts available on the current page
  • Available in the help context menu and under a ? keyboard shortcut
• A system for EUI components to expose and register their shortcuts

Phase 2

• Allow users to edit and disable keyboard shortcuts through the UI
  • Can start off as a setting saved in local storage and can eventually migrate to a user setting when that is available. (Doesn’t make sense as a space setting because these customizations will often be driven by unique reasons such as working with specific assistive tech or power-user specific workflows.)
  • This unlocks the capability to provide single key shortcuts (WCAG 2.1.4, any of which would right now pose as an WCAG A failure)

Future work

• Allow users to see and edit all keyboard shortcuts throughout Kibana
  • Can live somewhere in advanced settings (Use case is more centered around admin changing something for everyone because of collisions with other software or a user wanting to disable all keyboard shortcuts)
• Allow users to set keyboard shortcuts for commands registered without a shortcut
  • For example, could register “Create a new table visualization” as an action without a default keyboard shortcut. A user may find it useful to add this as a shortcut if it is a common action for them.
  • Ties in with future work of Global Search (anything that is available in global search is a good candidate to being available at a keyboard shortcut)

Accessibility notes

• Shortcuts fall in 3 categories: Navigation (move focus to a specific element), Activation (perform a specific action that does not have focus and may or maynot be visible), or Both
• Keyboard shortcuts should never be the only means of performing an action and should not replace appropriate focus order
• Avoid using any modifier keys (Meta, Alt/Option, Caps lock, Insert, Scroll lock)
• Avoid differentiating between capital and lowercase letters
• There is an HTML attribute called accesskey — unfortunately, it largely doesn’t do anything and is buggy in places where it should do something so it’s best to avoid it entirely
• Though not super well supported, we can enhance keyboard shortcuts by adding aria-keyshortcuts. The largest difficulty here will be updating these values when customized by users

Not addressed

1. Should CoreUI prescribe specific keyboard shortcuts or only create a mechanism for other teams to register theirs?
   • Common keyboard shortcuts seem to be:

     g+	Go to...
     ?	Help
     j/k	Next/Previous

2. How to handle localization? (Do we want to at all?)
3. Does global search become an all purpose command palette or do we keep these UIs separate?
4. How do we differentiate component specific shortcuts (such as code editors, EUI’s upcoming markdown editor, and other EUI components), page specific shortcuts, and global shortcuts?

Examples

1. Gmail has an extensive keyboard shortcut page that’s always available
   

   a. And allows for individually configuring each option, giving an alternative, and resetting all of it back to defaults
   

2. Google Calendar has a more modern design of Gmail’s implementation (but the only control is a on/off toggle). Twitter, Feedly, Google Keep, Trello — all have similar designs and implementations.
   

3. GitHub shows you the keyboard settings available on the page you’re on and links out to all keyboard settings (and has no controls for them)