Custom keyboard interaction

When building custom keyboard interaction, there are some requirements and conventional approaches to be aware of.

Common keyboard interaction patterns

For most user interface components or widgets, there are expected keyboard interaction patterns, just as there are conventional visual patterns that help users identify the type of content they are dealing with and how to interact with it.

It’s up to the designer and developer to implement the expected keyboard behaviours, whether it’s a simple control like a button, or a more complex user interface such as a modal dialog or a tabbed interface.

ARIA Authoring Practices

The ARIA Authoring Practices is a guide to building accessible custom interactive content using WAI-ARIA. In particular, see Patterns — ARIA Authoring Practices Guide — W3C.

It includes advice on how to implement the expected keyboard support for a good range of common widgets such as a:

• simple button
• modal dialog
• accordion (sections with show/hide functionality)
• disclosure (show/hide) widget
• tabbed interface.

For general instruction on how to approach your widget’s keyboard interaction, see Developing a Keyboard Interface — ARIA Authoring Practices Guide — W3C.

Keyboard shortcuts

Operating systems and applications, including web browsers, all have default keyboard shortcuts to enable easier keyboard access. However, there may be some scenarios where you consider implementing custom keyboard shortcuts.

Make sure that you understand the issues some keyboard shortcuts can cause and that you design them to be accessible.

Considering custom keyboard shortcuts

Consider the use case scenarios before you implement keyboard shortcuts.

For more complex widgets or web applications that people use over and over again, keyboard shortcuts can make navigating and operating them much easier for keyboard users.

However, for content that’s likely to be used only once, such as a newsletter subscription form, keyboard shortcuts are not particularly useful. In this case, the user first needs to learn the shortcuts that will help them complete the form, but once they’ve completed the task, they do not need to use them again.

Implementing custom keyboard shortcuts

For a custom keyboard shortcut to work, the web page needs to be listening for keyboard events initiated by the user. For more on how to do that, see Responding to keyboard input.

For more information on implementing keyboard shortcuts for your web page or app, see:

• Best Practices for Prototyping Keyboard Accessibility — Adobe XD Ideas
• J, K, or How to choose keyboard shortcuts for web applications — Sasha Maximova.

Avoid single character keyboard shortcuts

Single character keyboard shortcuts are keyboard shortcuts that use a single character key to initiate some command — for example, the D key for deleting the currently selected email in a webmail application.

Single character shortcuts can present real problems for both speech recognition users and people who are liable to hit the wrong keys on a keyboard.

If a single character shortcut is used, one of the following conditions must be met:

• there’s a way to turn off the shortcut
• there’s a way to change the shortcut to use one or more keys that do not print any characters, such as the Ctrl, Shift, Alt or F1–F12 keys
• the shortcut only works when the user interface component that it activates has keyboard focus.

Single character shortcuts and speech recognition

Speech recognition users speak to their web browsers. See Speech recognition — Knowledge Area: Assistive technologies.

If a web page includes single character keyboard shortcuts, what a user says could be interpreted by the speech recognition software as a string of single-letter commands that the browser then implements. This could lead to all sorts of things happening that the user did not intend, possibly with disastrous consequences — for example, if they accidentally delete or transform critical information.

For more on single character shortcuts and examples of their impact on speech recognition users, see:

• Understanding Success Criterion 2.1.4: Character Key Shortcuts — WCAG 2 — W3C
• Exploring WCAG 2.1 — 2.1.4 Character Key Shortcuts — Knowbility.

Meeting the Web Accessibility Standard

When single character shortcuts are implemented in a way such that they can be turned off, remapped using non-printable keys, or work only when the relevant control has focus, this meets WCAG 2 Success Criterion 2.1.4 Character Key Shortcuts (Level A).

Avoid accesskeys

The HTML accesskey attribute tells the browser what single character keys it can use to create a custom keyboard shortcut for activating or setting focus to an element.

To learn more about accesskey and why it should be avoided, see:

• Accesskey — WebAIM
• accesskey — MDN Web Docs
• The accesskey attribute — HTML Living Standard.

If keyboard shortcuts might help keyboard users or others to interact with your web application, instead of using accesskey, implement custom keyboard shortcuts.