You are currently viewing Success Criterion 2.1.4 Character Key Shortcuts

Success Criterion 2.1.4 Character Key Shortcuts

WCAG Principle: Operable

Guideline 2.1: Keyboard Accessible (Make all functionality available from a keyboard)

Conformance Level: A (Minimal Requirement)

What is Success Criterion 2.1.4?

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

  • Turn off: A mechanism is available to turn the shortcut off;
  • Remap: A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc);
  • Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.

Developers often design applications with character key shortcuts to boost productivity for keyboard users. These shortcuts might use a single key or a key combination. For instance, pressing “K” or the spacebar can toggle play-and-pause on a YouTube video.

While keyboard users find these shortcuts beneficial, they may pose problems for some assistive technology users. For instance, when using screen readers like NVDA, pressing the K key doesn’t play the video; instead, it navigates between links.

People using speech recognition software face a similar challenge, as they typically spell words letter by letter. This increases the chance of accidentally triggering shortcuts linked to single keys. Consider a transactions page where the key “d” deletes a transaction. If a voice command user searches for a term and says “d,” the system might delete a transaction rather than inputting the letter in the search box, hindering the user’s primary intent.

How does it make your website accessible?

Meeting success criterion 2.1.4 enhances web accessibility in several ways. It prevents users who rely on voice commands from unintentionally activating functions. It also protects users with motor difficulties from accidental actions due to inadvertent keystrokes. Most importantly, it ensures your website’s shortcuts don’t conflict with screen reader commands, offering visually impaired users a seamless navigation experience.

How to Meet Success Criterion 2.1.4

Common mistakes:

  • Assigning frequently used keys (like space or enter) as shortcuts without giving users control over them.
  • Overlapping shortcuts with common screen reader commands.
  • Not providing clear documentation or an option to change key shortcuts.

How to fix mistakes:

  • Change shortcuts from single-keys to combinations (e.g., “Ctrl + S” instead of just “S”).
  • Research common screen reader commands to avoid conflicts and test with actual screen reading software to ensure compatibility.
  • Clearly document all keyboard shortcuts, preferably in an easy-to-access location like a help menu or settings panel.

Helpful tips for developers:

  • Always give users the ability to turn off, remap, or make a shortcut only active upon focus.
  • Use established shortcut conventions when possible, like Ctrl+S for save, to align with user expectations.
  • Always provide audio feedback when a shortcut is used, such as a brief notification or sound, so users know the action was successful.

How to test if you've met compliance:

  • Find out whether there are any specific keyboard shortcuts on the website or app.
  • Check the settings if users have the option to turn off the shortcut or remap it to include one or more modifiers.
  • Verify if the keyboard shortcut works only when an element receives focus.

If checks #2 and #3 are true, then your website passes this success criterion.

Bad and Good Examples (Developer code)

bad Code Snippet

document.addEventListener('keydown', function(event) {
    if(event.key === 'B') {
        bookmarkPage();  // Bookmarking function

The code actively monitors for a ‘keydown’ event and activates the bookmarkPage() function upon detecting the ‘B’ key press. However, because it operates as an unrestricted global listener, pressing ‘B’ inadvertently triggers the function regardless of the user’s intention. This design flaw restricts accessibility for many users.

good Code Snippet

document.getElementById('bookmarkButton').addEventListener('focus', function() {
    this.addEventListener('keydown', function(event) {
        if(event.ctrlKey && event.key === 'B') {
            bookmarkPage();  // Bookmarking function

This code snippet corrects the problems of the previous example. The shortcut activates only when the element, like our hypothetical ‘bookmarkButton’, is in focus. This setup prevents unintentional triggers from accidental key presses outside this context.

Moreover, the shortcut combines ‘Ctrl + B’ rather than just ‘B’. This combination lessens the likelihood of accidental activations because it demands a deliberate key press. The code attaches the event listener to the ‘bookmarkButton’ only when it’s in focus, ensuring it doesn’t constantly monitor for the ‘keydown’ event in the background

Frequently Asked Questions

Can I have both single-character and combination shortcuts on my website?

Yes, but you must ensure that users can either turn off single-character shortcuts or activate them only when focused to avoid unintended actions and maintain accessibility.

Are there specific keys I should avoid using as shortcuts altogether?

While there’s no definitive list, be careful with keys frequently used in daily browsing, such as space or enter. Always research and avoid overlapping with common screen reader commands.

Are there tools or plugins available to help implement customizable keyboard shortcuts?

Yes, there are several libraries and plugins that can help manage keyboard shortcuts, like Mousetrap or jQuery Hotkeys. However, always use them in a way that complies with WCAG standards.

Are there any other WCAG criteria that relate to or intersect with Success Criterion 2.1.4?

yes. Several criteria, including 2.1.1 (Keyboard) and 2.1.2 (No Keyboard Trap) under the ‘Operable’ principle, emphasize keyboard access, user control, and predictability, complementing the aims of 2.1.4.

Ready To Become

Leave a Reply