One way to make a UI on the web keyboard accessible is to ensure parity between input methods: that things that can be clicked, can also be activated with just a keyboard. In addition, you can also introduce keyboard shortcuts for common actions. If you do, ensure they require a modifier key, like ⌃ Ctrl or ⌘ Cmd.

Understanding 2.1.4

In WCAG, the standard used to check if websites are accessible, there is a specific Success Criterion for keyboard shortcuts, which got added in version 2.1. From the criterion text:

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: (…)

In other words: do not use keyboard shortcuts that are just a one letter character (or multiple of those). After the quoted part, exceptions are listed where such a keyboard shortcut would be ok, we'll get to those later.

Let's first try and get a little more explicit. Basically, you could do shortcuts that are a single key, like, ‘press N to open a new document’. Or your shortcuts could be in the form of ⌘ Cmd + something or ⌃ Ctrl + something, requiring a modifier key. This Success Criterion basically says ‘don't do the single key thing, always have a modifier‘ (again, with exceptions, see below).

This criterion removes frustration for speech input users, who control their screen with their voice. Their software listens for words or sentences, but also for shortcuts. The issue is that shortcuts that don't use modifier keys could get activated up when the user didn't mean to.

An example from the Understanding document:

For example, Kim's email software uses common keyboard shortcuts to navigate ("k"), archive ("y") and mute messages ("m"). Her coworker enters her office and says "Hey Kim" and her microphone picks that up. The Y of "hey" archives the current message. K in "Kim" moves down one conversation and M mutes a message or thread.

(From: Understanding 2.1.4, Intent; adapted to be shorter)

The criterion also improves the experience for people who are prone to accidentally hit keys, like users with fine motor skill related impairments.

So basically, the issue with these “unmodified” shortcuts, is that it is harder for software to establish if the user actually wanted to trigger the shortcut. The use of modifier keys is an established pattern that captures this user intent, you would not press those and another key accidentally.

What about /?

When I was testing a website recently, I found that / was used as a keyboard shortcut. I wasn't a 100% sure if this was a WCAG failure per se. The Success Criterion text says keyboard shortcuts should not consist of just letter, punctuation, number of symbol characters. Is / any of those four things? Letters and numbers I know, but what exactly does the full set of punctuation and symbol characters look like? Why doesn't WCAG include a list?

Well, there are two answers to that:

• it's complicated; there are lots of languages and writing systems and it would be easy to forget a punctuation or symbol character… or even a letter of number, CJK languages have tens of thousands of characters
• what is really meant here is any character that prints something on the screen

That last answer is what Marjon from the accessibility consultancy Firm Ground replied when I asked about my confusion on Twitter. She linked to the WCAG Technique document (yup, not normative), where “all number, letter, sign and punctuation keys” are summarised as “printing characters”. That checks out. I'll take this interpretation: / is a printing character and should not be used as a shortcut on its own.

Exceptions

I promised to get back to the exceptions that are in the Success Criterion text. It says you can use single characters without modifier keys as shortcuts:

• if it the shortcut can be turned off in settings
• if the UI lets users remap the shortcut… so it's / by default, but users can go to the settings of your app and remap it to be ⌃ Ctrl + /
• if the shortcut works only when the relevant component has focus, for instance when you're in a countries select menu and press the T to jump straight to Taiwan (that way, it doesn't interfere)

The remapping option can get tricky if your interface has a lot of shortcuts. The popular email web app that allegedly was used as inspiration for this Success Criterion has a very large number of unmodified shortcuts, so many that it runs into the case where there aren't enough characters to remap them all.

Summing up

Keyboard shortcuts are most accessible when they include modifier keys like ⌃ Ctrl or ⌘ Cmd, so that they don't frustrate voice input users and users with fine motor impairments. If your interface has shortcuts that are just one or more “printing characters”, any character that prints something on the screen, best combine them with modifiers.

---

Originally posted as Keyboard shortcuts need modifier keys on Hidde's blog.

Reply via email