This post is available on my personal website and its content is shared here on dev.to.
Keyboard interfaces are an important part of any user-facing application. The ability to use the keyboard can help surface frequent or more complex tasks to the user, thereby increasing productivity and accessibility.
At the same time, we have to ensure that our application follow guidelines consistent with other applications and the platform running our interface (also known as the principle of least astonishment). Failure to do so would result in applications that require additional learning time and are more error-prone.
Therefore, deciding on which actions to make accessible to the user via keyboard shortcuts and the shortcuts to use are important UX considerations.
Note: keyboard navigation, although relying on the keyboard inputs, has different implications than keyboard shortcuts. See the ARIA authoring practices for more information on keyboard navigation.
When determining which shortcuts to add to an application, we can answer two high-level questions:
- Which actions should be accessible via a keyboard shortcut? Requires an understanding of the actions the user may take in a particular interface.
- Which keyboard shortcut should I use for this particular action? Requires an understanding of guidelines surrounding the design of keyboard interfaces.
When deciding on which actions to assign keyboard shortcuts, we should include common actions (such as copy/cut/paste, open, save, close, etc.) and application-specific actions the user will need to access regularly.
When selecting which key combination to use for each action, we can answer the following three questions:
- What is the standard key combination for a particular action? For example, saving is commonly accessible via Ctrl+S.
- What is the key combination found in similar applications? In a text editor, Ctrl+B bolds text. Other text editors should reuse this pattern.
- What is the key combination found in applications used alongside ours? For example, consider how GitHub or Bitbucket share similar keyboard shortcuts to code editors such as Atom or VS Code.
If designing a keyboard shortcut for functionality not found in existing applications, we should strive for shortcuts that are easy to remember and do not conflict with existing browser or operating system keyboard shortcuts.
Mnemonics (such as using Ctrl+U for Underline) can help make shortcuts easy to remember.
It is also important to consider localization when designing keyboard shortcuts, as different languages and keyboard layouts may make certain key combination less preferable (check out this list of keyboard layouts to determine which layouts are applicable to your application).
Most keyboard shortcuts use one or more modifier keys. Used effectively, they can help organize keyboard shortcuts and allow for multiple actions to be linked to one key (consider the relationship between Undo and Redo, using Ctrl+Z and Ctrl+Shift+Z respectively).
The modifier key to use for a particular action will depend on the platform:
- Windows/Linux — Ctrl for large-scale effects, Shift for actions that complement the existing standard shortcut. Alt and ⊞ Win should be avoided as they are used extensively for operating system functions.
- Apple — ⌘ Command should be used preferably, Shift for actions that complement the existing standard shortcut. Option should only be used when the ⌘ Command modifier is already taken. Ctrl should be avoided as it is used extensively for operating system functions.
Modifier keys are not always necessary. Interfaces that do not have a strong text entry focus can avoid modifier keys altogether (for example, GitHub or Photoshop). This can help speed up access to certain actions.
Web applications have to take into consideration three levels of scope inherent to their execution environment: the operating system, the browser, and the application itself.
In contrast to pointer-based inputs (mouse or touch gestures), it is difficult for the user to determine at which scope a particular keyboard shortcut will act on.
For pointer-based inputs, the visual hierarchy of UI elements on the screen will help the user identify what belongs to the operating system, the browser, or the application. This distinction is less clear for keyboard inputs. While the use of modifier keys can help label certain keyboard shortcuts as belonging to a certain scope (using the ⊞ Win modifiers for all OS-level shortcuts on Windows for example), these are not always obvious to the user and may be difficult to discover.
As an example, consider the difference between ⌘+←/→ and Ctrl+←/→ on Mac. The first is a browser-level shortcut, allowing the user to navigate between tabs. The second is an OS-level shortcut allowing the user to navigate desktop views.
As an application author, we should avoid keyboard shortcuts that override browser or OS defaults or are similar to existing system shortcuts.
Of course, as with everything when design web applications, we have to take into consideration the different platforms our application will run on. Keyboard shortcuts vary between operating systems and browsers and our applications should handle all these cases.
As a web application changes, the part of the user interface receiving keyboard input may change as a result. Dialogs, tree views, dropdown views may take priority in receiving keyboard inputs over the main application. The part of our interface that receives keyboard actions (eg. focus) needs to be clear to the user through some sort of visual indication.
Besides, there are no native approach on the web to restrict keyboard inputs to only a part of our web application (in the case of dialogs for example). We are responsible for implementing this logic.
It is important to ensure that keyboard shortcuts do not take different meaning in differerent parts of our application (for example Ctrl+D taking a different meaning across screens).
Applications usually provide a list of all keyboard shortcuts in a dedicated screen. However, other approaches exist to help introduce users to shortcuts as they interact with the application.
In general, when identifying an approach to let the user discover keyboard shortcuts, we can consider the following guidelines:
- Aim for solutions that allow for discovery through mouse-based inputs
- Look for incremental discovery
- Provide an easily accessible cheat sheet of important keyboard shortcuts
Keyboard chords and modes are core to Emacs and Vim. They are both examples of approaches to make a large number of actions accessible from the keyboard.
Chords (which consist of two keypresses to achieve a keyboard action) can be a powerful way to create more keyboard shortcuts using a common keyboard shortcut to start a chord sequence (Ctrl+C and Ctrl+X in Emacs).
Modes are a Vim feature that assigns different keyboard shortcuts depending on which mode is currently active.
Both these approaches are non-intuitive and require a significant amount of training from the user to learn the sequences for each keyboard action. Once the user becomes familiar with these interfaces, they can be a very effective way to expose a considerable number of actions with the keyboard. Chords and modes may only make sense in specialized applications where a large number of actions are available to the user at any point in time.
Palettes can provide an alternative that strikes a balance between ease of use and completeness. Palettes allow the user to search and select actions through a search bar which is usually invoked via a keyboard shortcut. Both Vim and Emacs provide this capability, but they have appeared in other applications such as VS Code or Figma for example.
In certain scenarios, allowing users to customize available keyboard shortcuts may make sense. Video games often allow users to modify keyboard mapping, to cater to the user's preferred gaming style, or support certain gaming hardware.
For complex applications, customizability can allow the user to adapt the interface to their preference, making the interface easier to use. The ability to customize keyboard shortcuts adds complexity, however, and most applications should not provide this feature.