Keyboard shortcuts need modifier keys

Published 2022-08-05 category: thoughts

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:

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:

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.

Thanks to Marjon Bakker and Eric Eggert for help with WCAG interpretation and Kilian Valkhof for the modifier key Wikipedia link.

Comments, likes & shares (58)

Jonathan Neal, Kilian Valkhof, Philippe Vayssière, Baldur Bjarnason, nic, Maksim Oreshek, Søren Birkemeyer, Mike-麥-Mai/index.html, knut, codeOfArmz, simeonGriggs, Sarah L. Fossheim (they/them), Kons Ti, Mark Hanna, Haz, Kristján Oddsson, ., Bastiaan van Zwieten, Johnny Taylor, Daniel Augusto, Jonathan Dallas, Anamika Singh, Tristan Harward, Kap 🔥, Charles Hall, hawkupr, Luz De León, Kristóf Poduszló 🦄, Paul J. Adam, Bhupesh Singh, Thomas Bassetto, ☯Evil Jim O'Donnell, Alistair Shepherd, Markus Schork, Hendrik and Konstantin Rouda liked this

Vadim Makeev 💙💛, Mike-麥-Mai/index.html, Sarah L. Fossheim (they/them), Mark Hanna, Bastiaan van Zwieten, Luz De León, Paul J. Adam, Bhupesh Singh, Hadley and Matthew Deeprose reposted this

Apps that have keyboard shortcuts that are triggered without modifier keys are also a UX disaster. Most apps these days have non-existent focus indicators. Combine that with modifier-less shortcuts and you have a recipe for an end-user regularly nuking their work just by typing
Great post! The modifier key is the meta key on Apple devices, right? As folks can setup shortcuts for their non hot key, do you use code like this? It ensures platforms get the hot key they expected. Also, is ‘modifier key’ a clearer term for this, or is it too generic?
Great post! My users have been trained to press "f" to open a component similar to Apple's Spotlight for years, no modifier key needed. I think Ctrl+f would be the the better shortcut, as Cmd+f is already taken. Changing this after years can be painful for users 🙁 Tough luck.
I believe “modifier key” in the WCAG sense would be anything that doesn't print stuff on the page, so could include Ctrl, Option and Command on Mac, and maybe Shift but I believe there are specifics around Shift that make it less suitable
and I think that sort of tests in code totally makes sense to have yes, so you can be close to what would feel like the most common modifier/hot key
Shift is a modifier too (it quite literally modifies!) Look there's even a wikipedia article for the definition en.wikipedia.org/wiki/Modifier_…
wait, there is a wiki page for this stuff!?
Thank you, both! @kilianvalkhof, for what I’m trying to do (which is to detect whether the key most associated with shortcuts was used pressed during a keyboard event) would you think ‘hot key’ is an appropriate description?
brb going to add those ⌘/^ symbols in my post
In Polypane (and the page below) I automatically switch between those and the win/linux ones. that'd make it extra fancy. polypane.app/docs/list-of-s…
do you have to worry about conflicts with browser keyboard shortcuts when you start using modifiers?
I believe so!