KimPatch
commented
7 years ago My notes from 2017-05-11 call: Version at end of call: "If a shortcut consisting entirely of character keys is implemented by the web page to activate a control, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key."
-
@mbgower Suggestion to change "at least one non-character key" to "modifier key". If we do this, we lose the ability to change a single character key shortcut to, for instance, F10. I think clarifying that Space and Enter are not character keys may address the concern that led to the suggestion. There may be an argument that they are printable, but they're not characters. We could clear up any possible misunderstanding by specifying this in the definition: Character key: any keyboard character that is printable, i.e. letters of the alphabet including capitals, punctuation, numbers, and symbols. Note that the Space and Enter keys, which return empty spaces rather than characters, are not character keys.
-
@Ryladog If a shortcut consisting entirely of character keys is implemented to activate a custom control… change suggested because of concern about Access keys. My understanding of access keys is that they are always modifier keys, not single character keys, so there is no actual clash here. Is this correct? I think the concern was that there might be a misunderstanding that access keys might fall under this. But from the user's point of view doesn't matter what type of shortcut it is, single character is going to mess them up. Would it help to add a note to the understanding that this does not affect any controls including access keys that use modifier keys?
-
Greg pointed out use cases that involve more than one character key, including add-ons like vim that enable shortcuts that are strings of character keys, any assistive technology that pipes a string into an application, and typing ahead using high magnification.
-
One other thing that we talked about: our current examples – Gmail, Twitter, Github, Google docs – all use role = application. Suggestion to narrow SC to specify role = application. But looking to the future it would be better to keep it broad.
-
Jason White comments from the survey need to be addressed – I'll address them in a separate entry.
johnfoliot
mbgower
jasonwhite
mraccess77
DavidMacDonald
Ryladog
greg-lowney
patrickhlauke
kwahlbin
Current versions of SC and Definitions
Open issues and Surveys
Open issues: https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_status#Issue_69_-_Single_key_shortcut_alternative Surveys: (Links to surveys require W3C Member access)
SC Shortname
Character Key Shortcuts
SC Text
If a keyboard shortcut consisting entirely of one or more character keys is implemented by the content, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key.
Suggestion for Priority Level (A/AA/AAA)
Level A
Related Glossary additions or changes:
Keyboard shortcut: An alternative means of triggering an action by the pressing of one or more keys.
Character key: single printable Unicode code point, any keyboard character that is printable, i.e. letters of the alphabet including capitals, punctuation, numbers, and symbols. Note that the Space and Enter keys, which return empty spaces rather than characters, are not character keys.
What Principle and Guideline the SC falls within.
Principle 2, guideline 4
Description
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 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 implemented to carry out a control, or 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).
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.
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.
Keyboard-only users who have mobility issues can also be prone to accidentally hitting keys. Those users would be able to to avoid problematic single character shortcuts by turning off or modifying the shortcuts to include more than one key.Keyboard-only users who have mobility issues can also be prone to accidentally hitting keys. Those users would be able to to avoid problematic single character shortcuts by turning off or modifying the shortcuts to include more than one key.
Example 1
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.
Example 2
A keyboard-only user is using Github and 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.
Testability
Identify all shortcuts that can be used. If single key shortcuts are used, check if the user can turn off shortcuts or remap them to other shortcut keys.
Techniques