joshueoconnor
commented
7 years ago Based on comments from @jasonwhite AGWG has requested the APA group for feedback on this. [1]
[1] https://www.w3.org/2002/09/wbs/35422/character-key-issue69/results
Closed kwahlbin closed 7 years ago
joshueoconnor
commented
7 years ago Based on comments from @jasonwhite AGWG has requested the APA group for feedback on this. [1]
[1] https://www.w3.org/2002/09/wbs/35422/character-key-issue69/results
mbgower
commented
7 years ago Since @joshueoconnor has referenced the survey and comments from @jasonwhite, @jnurthen and Oliver Keim , I'm going to address each of the comments there in turn.
The key message I'm trying to convey is that modifier keys are an established affordance for users to trigger actions. They provide predictability and signal user intent. Take away a user's ability to use them, and you increase the potential for errors and unexpected results.
If the user interface control that has focus (including its role) can be "programmatically determined", then speech recognition systems can implement a policy of not forwarding dictated text (e.g., as simulated keystrokes) to the browser whenever the currently focused control is not editable text.
There has been such discussion before, and I agree that speech recognition implementations could be much improved. However, it does not address the use case I have been focusing on (which applies to all keyboard users, so by extension, speech recognition users too).
Here is the problem in a nutshell. If the application has single-key shortcuts, the application has no way of knowing when a character key is intended by the user for input or when it is intended for activating a shortcut. It can infer that keystrokes provided when focus is in an input are intended for input and that when focus is not in an input field, the keystrokes are intended as actions.
But if the user for any reason has unintentionally moved focus onto or off of an input field, then the user's intended actions are going to be misinterpreted. If this happens in an input, it is a relatively minor issue in almost all scenarios (with the common symptom occasional odd characters in a text field) .
But if the reverse happens -- I'm inputting text to a field and focus moves off the field -- then I can potentially lose work or activate actions I did not intend. Even if there are safeguards for such matters in the form of dialog boxes, those can also be accidentally activated in the act of typing a stream of input characters (e.g., I press Enter and activate the default action, or I press the key that is the shortcut key for one of the buttons in a dialog (e.g., Y for "yes").
Character Key Shortcuts help to improve keyboard efficiency
Yes, they can, and this SC is not saying they cannot be used. It is saying that the user should have an option of turning them off since they are non-standard behaviour, and can have unforseen consequences.
A command vector based on character keys is much easier to implement as most of the User Agents (namely Browsers) have inconsistent keyboard shortcut architectures for Hotkeys (triggering commands without focus change) and Accesskeys (changing focus without automatically triggering commands).
You are describing a problem with the state of the technology. I agree that implementation of keyboard command shortcuts in user agents is an issue, and has resulted in some literature warning developers off using them. But that doesn't mean there cannot be better implementations or solutions.
The fact all (as far as I know) operating systems require modifier keys for keyboard commands shows that there are very good reasons for them. Namely, the modifier key shows the intent of the user.
This SC is all about ensuring the users can have a more predictable experience. If an application has implemented single-key shortcuts well and I have no conflicting habits or technologies, it can improve my user experience. But if there are design shortcomings that make it unclear where my focus is, or a condition I have causes frequent accidental changes of focus in a UI, then an ability to turn off the single-key shortcuts and use typical modifier key combinations, is going to allow me to use the application.
marcjohlic
commented
7 years ago Character Key Shortcuts help to improve keyboard efficiency
Yes, they can, and this SC is not saying they cannot be used. It is saying that the user should have an option of turning them off since they are non-standard behaviour, and can have unforseen consequences.
+1 to Mike's and Kim's comments.
I think it's important to again clarify that this SC is not restricting the use of character key shortcuts. It's simply saying that if you do use them, ensure users can either turn them off or remap them.
Everybody wins.
johnfoliot
commented
7 years ago Mike wrote:
the modifier key shows the intent of the user
Current Draft 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.
Hi all,
I think this is actually the key: the end user needs a method of indicating that they want either of a) a key-stroke shortcut, or b) to actually type the actual character mapped to the specific key. This holds true for all languages and keyboards (i18n issues).
Currently, as I understand the intent, the draft text is seeking to be able to re-map a single-key to another (non-character) single key, and while this may address some issues, it potentially also introduces others: for one, there may not be enough "non-character" keys on any given keyboard to allow for a full re-mapping.
For example, a quick check of Gmail (the poster-child for this SC) shows me that there are currently 19 alpha-character, single-keystroke shortcuts already, with an additional 18 non-alpha-character keys (eg.: {, }, [, ], etc.) being used, for a total of 37 single-keystroke shortcuts (there are additional multi-key shortcuts as well). Given the simple math that on Western keyboards we only have 26 alpha-characters to choose from, I think we can see how this becomes problematic...
Get to the point JF:
While I agree with the need to be able to activate or "turn off" this type of function/feature is an important need, I believe that instead of attempting to remap "N" to "~" (or some such), that instead what is really required is for impacted users to instead be able to signal their intent of what they want to do when a keystroke is invoked.
the modifier key shows the intent of the user
thus, I am suggesting that we re-contemplate this SC to instead read something like:
If a scripted 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 to add a user-determined modifier key to the shortcut sequence.
While I am quite open to additional editorial word-smithing here , I believe that this gets us further to the heart of the issue, provides an equitable and workable solution, and addresses the limited number of potential alternatives (for keys).
Kim, as the principle driver of this SC, would this meet the declared need in both theory and practice? What do others think of this proposal?
JF
On Fri, Jun 9, 2017 at 9:15 AM, Marc Johlic notifications@github.com wrote:
Character Key Shortcuts help to improve keyboard efficiency
Yes, they can, and this SC is not saying they cannot be used. It is saying that the user should have an option of turning them off since they are non-standard behaviour, and can have unforseen consequences.
+1 to Mike's and Kim's comments.
I think it's important to again clarify that this SC is not restricting the use of character key shortcuts. It's simply saying that if you do use them, ensure users can either turn them off or remap them.
Everybody wins.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/69#issuecomment-307400718, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c3A9iBtqtWsQDCG5wtYGOfXIWzakks5sCVOBgaJpZM4K-jN2 .
-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com
Advancing the mission of digital accessibility and inclusion
mbgower
commented
7 years ago Hi John, In my opinion, what you have done is substitute less prescriptive language with something which seems more prescriptive. If this SC is adopted as currently worded, there is nothing stopping it having a recommended technique which involves personalization in a way you describe. But I don't see why authors should be restricted to a user-determined solution.
To switch the focus to the non-web world, the number of software applications that assign non-customizable shortcuts is far greater than the number that allow personalization. I don't see a reason why we should make the web more prescriptive.
You also suggest putting in the word "modifier key". One of the reasons the current SC specifically says non-character key is to keep author options open. I believe a "modifier key" is a subset of non-printable keys. But other keys could be used as equivalent to modifier keys. Perhaps this just comes down to a definition, but when I see modifier, I think only Ctrl, Alt, Shift, Command, Option. But there are other non-printable character that could also be used by an application for the same key-combination purpose.
Finally, your changes are subtle enough that I think they can be called out as considerations in an editors' note. I really feel that when we're getting down to differences in phrases to describe similar things, editors' notes that capture such considerations may be a way of pushing the SC out for public input without us spending weeks trying to arrive at wording we all agree on (when the reality is these are likely to be adapted based on feedback anyway).
Others may still have objections to the whole SC, and obviously those need to be addressed.
KimPatch
commented
7 years ago @johnfoliot @mbgower I think we generally need to be less prescriptive. It's difficult to picture everything users might do.
What works for me, and the way I advise speech input users to adjust Gmail shortcuts, is to put a "+" in front of every shortcut. This keeps them discoverable, easily accessible, and this combination is more likely to be available than modifier key combinations. I can look at the existing keyboard shortcut cheat sheet and speak any standard shortcut prefaced by "Plus", which is also relatively easy to say. Then, for commands I use a lot, I can write macros that call the keystrokes using a couple of logical words – a native speech command. This type of shortcut isn't much good for a keyboard user because it's not physically convenient to press Plus and another letter at the same time. That's why modifier keys are where they are on the keyboard – for ease-of-use for keyboard users.
An even better shortcut solution for speech input users is to substitute single-character shortcuts with a string of characters – this would, in one fell swoop, eliminate the single character key problem and enable native speech commands for any speech engine. This type of shortcut, of course, generally only works for speech input users, so it's a technique above.
Strictly speaking, neither of these scenarios is covered by the non-character key version, but they can be techniques to offer choices in addition to the non-character key version that's the best line to draw for users with mobility issues. And even the non-character key version is a huge step in the right direction for speech users – it makes things much better. But it's going in the wrong direction to narrow it still further.
Bottom line: I agree that if the problem is that there aren't enough keys, it's not solving it to limit user options to an even more restrictive subset than non-character keys.
@mbgower I like your earlier explanation of the focus issue.
mbgower
commented
7 years ago @kwahlbin, given your examples, maybe incorporating @johnfoliot's scenario for a user-provided shortcut is prudent.
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 remap it to a shortcut that is either user determined or uses at least one non-character key.
awkawk
commented
7 years ago Merged with editor's draft.
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