Proposed Single Key Shortcut Alternative

From Mobile Accessibility Task Force

Proposed SC Shortname

Single key shortcut alternative

Proposed SC Text

If a single character shortcut is used to carry out an action on a webpage,

  1. it is not the only means to carry out that action, or
  2. a mechanism is available to turn all single character shortcuts off

Extension Reference

Suggested Priority Level

Level A

Suggested Glossary additions or changes

Associated Principle and Guideline *or* proposed Guideline the SC falls within

Proposed SC Intent

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 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 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.

If the cursor focus is in the gmail main window, for instance, 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 app that doesn't use single-character shortcuts nothing happens (or if the focus is in text field there's a bit of stray text that be easily seen and undone.)

So to fully include speech users, single-key shortcuts must not be the only way to carry out a control, and a mechanism must be available to turn off all 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).

Proposed SC Examples

A speech user is checking Gmail. 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.

Proposed SC Benefits

Speech users will be able to turn off single key shortcuts so they can avoid accidentally firing batches of them at once. This will allow speech users to make full use of programs that offer single key shortcuts to keyboard users.

Evidence

Testability

Techniques

Resources

Mobile devices are gaining keyboard shortcuts:

Web programs that employ single key shortcuts:

Comment

Boneyard

Guide