Understanding Character-key Shortcuts

Intent

Character-key shortcuts work well for many keyboard users, but are inappropriate and frustrating for speech input users, whose means of input is strings of letters, and for keyboard users who are prone to accidentally hitting keys.

So to fully include speech users and keyboard users who are prone to accidentally hitting keys, users must be able to turn off or reconfigure single key shortcuts.

This success criterion is becoming increasingly important in the mobile realm as growing number of apps more fully enable keyboard controls (see resources).

Note that this doesn’t affect components such as list boxes and drop-down menus that contain words that may be selected by one or more character keys, because the container is first accessed or opened with an initial, non-single character shortcut, e.g. “ALT” or “ALT-F”. This makes the full path to invoking a menu or drop-down item a two-step shortcut that includes a nonprinting key.

Note that Accesskeys are not affected because they include modifier keys.

Background on the mechanics of speech input: Speech Input users generally work in a single mode where they can use a mix of dictation and speech commands. This works well because the user knows to pause before and after commands, and commands are usually at least two words long. So, for instance, a user might say a bit of dictation, e.g. "the small boat", then pause, and say a command to delete that dictation, e.g. "Delete Line". In contrast, if the user were to say the two phrases together without a pause, the whole phrase would come out as dictation, e.g. "the small boat delete line". Although speech input programs often include modes that listen only for dictation or only for commands, most speech users use the all-encompassing mode all the time because it is a much more efficient workflow (it would increase command inefficiency by 300% if users were to change to command mode and back before and after issuing a command).

Speech users can also speak most keyboard commands, e.g. "press Control Foxtrot" without any problems. If the website or app is keyboard enabled, the speech user can also write a native speech macro that calls the keyboard command, e.g. "This Print" to carry out "Ctrl+F"

Single key shortcuts are the exception. While using single letter keys as controls might be appropriate and efficient for many keyboard users, single key shortcuts are disastrous for speech users. Because only a single key is used to trip a command, a spoken word can become a barrage of single key commands if the cursor focus happens to be in the wrong place.

Here's a real-life example: If the cursor focus is in the main window of a web mail application that uses common keyboard shortcuts to navigate, archive and mute messages (for instance, "k", "y" and "m"), and someone enters an office and says "Hey Kim" and the speech user's microphone picks that up, "y" archives the current message. "k" moves down one conversation and "m" mutes a message or thread. Or, if the speech user looks up and says "Hey Mike" without remembering to turn off the microphone, the same three things happen in a different sequence. In contrast, in a webpage or web app that doesn't use single-character shortcuts nothing happens (or if the focus is in text field a phrase that's accidentally picked up by the speech microphone results only in bit of stray text that be easily seen and undone.)

Benefits

Examples

Example 1: Disable Shortcuts

A mechanism is provided to allow users to disable character-key shortcuts. The character key shortcuts were not the only way to carry out these commands.

Here's a real-life example: A speech user is checking mail. A colleague enters the office and says "Hey Kim" before the speech user can turn off her microphone and the microphone picks up the colleagues greeting. Because the speech user has turned off single key shortcuts, The three letters that, when they are single key shortcuts, carry out actions – "y" for archive, "k" for move down one conversation and "m" form you conversation – did not carry out any actions.

Example 2: Alternate Control

A mechanism is provided to allow users to change character-key shortcuts

Here's an example: A keyboard-only user is in a long issues thread. While reading the thread she accidentally hits the “s” key, which moves focus to the search bar at the top of the document. This causes her to lose her place and her train of thought. She changes the shortcut to include another key so she can avoid future interruptions.

Example 3: Shared Alternate Control

A mechanism is provided to allow users to change character-key shortcuts in such a way that the changes can be saved and shared with other users

Example 4: Native Speech Alternate Control

A mechanism is provided to allow users to change character-key shortcuts including to strings of up to 25 characters. These can directly serve as native speech commands for any speech engine.

Resources

Web apps that use character-key shortcuts and allow users to disable and/or change these shortcuts:

Videos of speech user trouble with single character key shortcuts:

Techniques

Sufficient

  • Ensuring that users have a way to to turn off single key shortcuts
  • Providing a mechanism for users to remap shortcut keys
  • Providing a mechanism to adjust any customizable key shortcut on the webpage to an alternative control of a string of up to 25 Characters, including spaces.

Advisory

Failure