Understanding Character-key Shortcuts

Intent

The intent of this Success Criterion is to ensure that users who rely on speech-to-text technologies are able to consume and interact with content without the disruptions that can occur when spoken words and sounds are converted to keypresses that inadvertantly invoke functionality in the content. Keyboard users with mobility issues who are more likely to accidentally activate keyboard shortcuts are also expected to benefit from this Success Criterion.

Speech Input users generally work in a 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. Speech users can also speak most keyboard commands, e.g. "press Control F" without any problems.

Single letter keys as controls may be appropriate and efficient for keyboard users, but single key shortcuts create substantial problems for speech users. When a command is executed using only a single key, a spoken word can become a barrage of single key commands that have unpredictable results.

This Success Criterion 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.

Use of HTML accesskeys is not expected to be a problem since accesskey shortcuts are invoked in combination with modifier keys.

Benefits

Examples

Example

A speech user is checking webmail. A colleague enters the office and says "Hey Kim" before the speech user can turn off her microphone. The webmail tool allows users to turn off single key shortcuts in settings so even though the speech tool sends the keypresses contained in "Hey Kim" to the system, the three letters that were originally set up as single key shortcuts ("y" for archive a message, "k" to move down one thread, and "m" to mute the thread) did not carry out any inadvertant actions.

Example

A web application provides a mechanism for users to add a non-printing character as a modifier key to existing shortcuts.

Failure Example

A keyboard-only user is using a discussion board and is in a long threaded conversation. 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.

Resources

Techniques

Sufficient

Situation

Advisory

Techniques that are not sufficient by themselves to meet the Guideline or Success Criterion.

Same template as sufficient techniques.

Failure

Techniques that document conditions that would cause the page not to meet the Guideline or Success Criterion, even if sufficient techniques are also used.

Same template as sufficient techniques.