Single key shortcut alternative

[kwahlbin]

Current versions of SC and Definitions

• SC for viewing | SC for editing
• Character Key definition for viewing | Character Key definition for editing
• Keyboard Shortcut for viewing | keyboard shortcut definition for editing
• Understanding document for viewing | Understanding document for editing
• SC in full draft guideline

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)

• Results of Questionnaire Timeouts April 18, 2017

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

1. Allow users to turn off single key shortcuts
2. Provide a way for users to remap shortcut keys
3. The user can adjust any customizable key shortcut on the webpage to an alternative control of a string of up to 25 Characters, including spaces.

[alastc]

Looks good to me, very clear.

As a very minor thing, I wonder if the word keyboard should be used with "a single character shortcut". I.e. "a single character keyboard shortcut". If other people understand it straight away then don't worry about this comment.

[mbgower]

I need a clearer definition of "single character". I'm assuming you don't mean single key, since that would cause Delete, Backspace and all other operation keys to fail. Pressing a single alpha character in a Select element causes it to jump to the first item beginning with this letter. I would consider that carrying out an action. I'm assuming it would not be included in this. What about selecting menu items by first character?

Taking this candidate beyond web pages (remembering that 508R and M376 are both using WCAG as their standard to apply to software, etc) it would mean all the tile keys on Microsoft Office ribbons would fail.

On DNS on the desktop, you have to preface any command with a word (i.e., "Press E") What you are describing seems to be a failure of the AT. I'll get some more background and let this SC sink in a bit more, but at first glance, it seems problematic.

[KimPatch]

• A character is a letter, number or symbol. A single character shortcut is a shortcut of just a single letter, number or symbol key. We could say "single character keyboard shortcut", and I won't argue if everyone really wants to do that, but my first inclination is to not specify keyboard because if there's a way to indicate a single character key that's not tied to a keyboard and if a speech macro were to call that it would cause the same end-user problem.
• Menus are a little different because to get to the single-key controls you first need to drop-down the menu. So there is a non-single-key command that’s a gatekeeper. So it’s not really a single key shortcut, it’s a two-part shortcut consisting of a key combination, then a single key. Same with the Microsoft ribbon.
• It's not a failure of the AT. "Press E" is a command. Dragon also lets you dictate words and phrases. The problem with single-key commands is that a word or phrase can also be a string of single-key commands and cause much harm in doing so.

[mbgower]

Oh, lightbulb! This SC is an attempt to prevent user error. I didn't get that until now.

If the cursor focus is in the gmail main window, for instance, and someone enters an office and says "Hey Kim"

So what you are concerned with is where text strings are sent to the page when the user is not in an edit field. It's not restricted to speech; this issue will happen if I start typing in gmail without being in the compose field, but I take your point that it is more likely to happen to someone who dictates and has forgotten to turn off their mic. I'd say this is another issue that could be addressed with personalization.

Okay, I understand the context more. However, I still have cautions around language here, because I wouldn't want this SC to inadvertently cause a lot of hassles for other user groups. Altering the short name so it refers to character keys and not any old key would cover some of my concerns, but not all.

For instance, just to be clear, what you say in the following is not entirely accurate:

Menus are a little different because to get to the single-key controls you first need to drop-down the menu. So there is a non-single-key command that’s a gatekeeper. So it’s not really a single key shortcut, it’s a two-part shortcut consisting of a key combination, then a single key. Same with the Microsoft ribbon.

Here's a sequence of single character commands, with no combinations required:

1. Press ALT [ menu bar comes into focus]
2. Press F [file menu opens]
3. Press P [print dialog opens]

So I think we have to be more careful about how "carrry out an action" is defined. I'll put that in a different comment.

[mbgower]

Here are two considerations:

1. are there situations where pressing a single character key can and should trigger interaction?

The answer is yes: pressing any alpha character to jump by letter through a Select listbox; pressing alpha characters to select a designated item in a menu. There are plenty of scenarios that involve non-character keys, but I'm assuming we now have that covered.

2. are such situations dependent on a user entering an element or context?

Yes, in each case I can think of, the user must have placed the focus into a mode that 'listens' for the keys (i.e., the focus needs to already be in a listbox, or in a menu).

So if we can find a means to clearly state that such scenarios are exempt, we're left with a situation where the true sense of shortcut applies, and I'm a lot more comfortable with this concept.

I'll close by stating that I think these single keystroke shortcuts arose partly due to the restrictions on multiple-key shortcuts that exist on the web, where the page must compete with all browser and AT shortcuts. If we can find a way to allow keyboard users to get full control in the modifier keys for page interaction (say, by making User Agent shortcuts invalid when the browser is in full screen or similar mode) it will go a long way to resolving the issue. And again, personalization attributes and corresponding user settings seem like they would really help too.

[alastc]

What if the first line of the SC were about added keyboard shortcuts to differentiate from default ones?

Something like:

For single character shortcuts added to a webpage that perform an action:

Also, I just wanted to point out that adding keyboard short cuts is something developers have to do as extra, so having a control to switch off that functionality should then be relatively straightforward. (Also, given the lack of always-on keyboard on small/mobile devices, why would anyone rely on these shortcuts?)

For example, Gmail allows you to disable all the single-character shortcuts. (See the list and the control by typing shift and "?" when in the Gmail interface. So I assume that Gmail would pass because you can turn them off?

I guess I'm just saying that the impact of this SC (in terms of feasibility/hardship for authors) does not seem that big to me.

[KimPatch]

@mbgower Let me reword this to make it accurate:
Menus are a little different because to get to the single-key controls you first need to drop-down the menu. So there is a non-single- character- key command that’s a gatekeeper, e.g. the ALT key. So it’s not really a single character key shortcut, it’s a two-part shortcut consisting of a non-single-character-key shortcut, then a single-character-key. Same with the Microsoft ribbon.

[mbgower]

Yep, thanks @KimPatch, using "character" definitely reduces confusion.

[mbgower]

For single character shortcuts added to a webpage that perform an action:

+1

[DavidMacDonald]

@KimPatch @kwahlbin I think it can be done without the bullets and shorter:

Single character shortcuts are not the only way activate a control, unless a mechanism is available to turn them off or remap them to shortcuts with two or more characters.

Glossary
Single character shortcut: Mechanism added to the content which triggers a control using only one character on the keyboard (such as ACCESSKEY in HTML)

[awkawk]

Updated the issue description to reflect the FPWD text.

[DavidMacDonald]

comments from Greg L.

The final "two or more characters" should be "include at least one non-character key", as Ctrl+F is fine, as is PgDn. I would actually prefer "If a key shortcut using only printing characters is implemented by the web page to activate a control, then a mechanism is available to turn them off or remap them to a shortcut that uses at least one non-printing key

@KimPatch can you comment?

[KimPatch]

I like this rewording, but we also need to make sure not to block the developer from providing the user with the even better choice of remapping to native speech shortcuts of a string of printing characters (this would allow a Gmail user to enable, for instance, "Reply to All" in place of "a", "This Mute", in place of "m" or "This Archive" in place of "y", no matter what speech engine was being used).
So maybe "…remap to a shortcut that has the option to include at least one non-printing key or a string of as many as 25 printing characters."

[mbgower]

Where did "printing" character come from? Don't like that term.

[mbgower]

we also need to make sure not to block the developer from providing the user with the even better choice of remapping to native speech shortcuts of a string of printing characters (this would allow a Gmail user to enable, for instance, "Reply to All" in place of "a", "This Mute", in place of "m" or "This Archive" in place of "y", no matter what speech engine was being used).

Besides the fact i think that can be better handled by the speech solution allowing for the selection of labels, etc., the develop is not blocked by doing that with the current langugage. As well, that is very prescriptive to put into the SC. If you make the requirement less specific, it doesn't prevent that as a solution.
I believe we are trying to say 'if someone has a single-character shortcut, give the ability to turn it off or alter the shortcut to a non-single character." We also need to ensure we indicate in definitions that:

1. what a single-character shortcut is and is not (especially mentioning modifier keys)
2. that when a user has entered a mode or widget like a menu, single key shortcuts are acceptable. Otherwise, single characters to jump in a listbox, or to select items in a menu, etc., would be disallowed

We may want to consider addressing in the Understanding doc that this is specific to application-wide shortcuts, or something, to clarify this. The topic has been explored before. I just think it needs to be clear #69 (comment)

[DavidMacDonald]

@KimPatch

single characters to jump in a listbox, or to select items in a menu, etc., would be disallowed

Could we address this by exempting anything that is closed until it has focus. (Listboxes, dropdown menus etc...)?

Definition Single key shortcut

A printing key (not a modifier key) that .... e.g. the ALT key. So it’s not really a single character key shortcut, it’s a two-part shortcut consisting of a non-single-character-key shortcut, then a single-character-key. Same with the Microsoft ribbon.

[mraccess77]

Could we address this by exempting anything that is closed until it has focus. (Listboxes, dropdown menus etc...)?

List boxes may always be open with no way to close them. It's the browser standard behavior to support first letter navigation.

[DavidMacDonald]

hmmm....

so a combo box forced open by a browser with first letter navigation could complicate this SC?

Kim feels that a first letter navigation in combo and drop down menus are two step components so not single keys ...

[KimPatch]

@mbgower @DavidMacDonald

that when a user has entered a mode or widget like a menu, single key shortcuts are acceptable. Otherwise, single characters to jump in a listbox, or to select items in a menu, etc., would be disallowed

Yes, list boxes, drop-down menus etc. need to be opened with an initial non-single character shortcut, so going that path to invoke an element is not a single character shortcut, it's a two-step process. As long as the first step in any process is not a single character shortcut it doesn't matter what happens after. (As an aside, first-letter navigation on menus works very well for speech users. It sets them up to get to any menu item with a single speech command. I advise developers to follow this good standard way of enabling menus.)

If a developer decides to invoke something deep within a menu with a single character keyshortcut without going through the menu, however, that is a single character key shortcut. So it's not so much where it appears as how it acts.

[mraccess77]

My point is that listboxes can be always expanded without an option to collapse them.
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_select_multiple. But the single letter keys only work when the listbox is focused.

[mbgower]

As long as the first step in any process is not a single character shortcut it doesn't matter what happens after.... (As an aside, first-letter navigation on menus works very well for speech users. It sets them up to get to any menu item with a single speech command. I advise developers to follow this good standard way of enabling menus.)

Right. I was just emphasizing that that needs to be conveyed in the Understanding doc, at the least, and if we can work the exception for two-step processes into the SC text, it would be good. What we are talking about here as the primary culprit are the one-character shortcuts that are constantly listening, as opposed to ones that are triggered once you're inside a two-step process.

[KimPatch]

got it – I agree

[KimPatch]

More on this wording originally from Greg (edited):
"If a key shortcut that consists of a single printing character is implemented by the web page to activate a control, then a mechanism is available to it off or to remap it to a shortcut that uses at least one non-printing key."

I'm okay with using either single character key shortcut or single printing character. I think the advantage of printing character is it addresses two problems in two different populations. Keyboard users with mobility issues are likely to hit any single physical key, and some keyboard layouts may be different. And capital letters are just as dangerous for speech users. Question: is there a disadvantage that I'm not thinking of to using single printing character?

[mbgower]

Question: is there a disadvantage that I'm not thinking of to using single printing character?

I'm concerned about the concept of "printing characters" simply because I don't find it as intuitive as "single character keys". My mind gets pulled off by the word 'printing'. What is the advantage? To me, we find the most immediately grasped phrase, and then include a definition.

[KimPatch]

I agree. It is confusing to add the concept of printing, especially at the beginning.
Does this work?
Short name: Character key shortcuts
SC:
"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-printing key."
Definition:
Character key: any keyboard character that is printable, i.e. letters of the alphabet including capitals, punctuation, numbers, and symbols.

This addresses one-and two character shortcuts that cause problems for speech input users, including capital letters. And it addresses single-key shortcuts that cause problems for folks who have mobility issues, including symbol keys.

[DavidMacDonald]

What about "alphanumeric keys"... isn't that what we are talking about?

@mraccess77

But the single letter keys only work when the listbox is focused.

With the new language proposal from @KimPatch we need to plug the hole for drop downs etc... I've added "that is not focused"

Short Name: Shortcuts

If a shortcut consisting entirely of alphanumeric keys is implemented by the web page to activate a control in a component that is not focused, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-printing key.

Alpha-numeric keys: Any keyboard character that is printable, i.e. letters of the alphabet including capitals, punctuation, numbers, and symbols.

Hmmm, ... is a comma alphanumeric?

Turns out "ASCII printable characters" is a thing. http://www.theasciicode.com.ar/ascii-printable-characters/comma-ascii-code-44.html
Which makes "printable characters" more attractive.

@KimPatch BTW would this last proposal inhibit authors from providing a way to create custom spoken commands?

[KimPatch]

@mgower @DavidMacDonald @Ryladog

1 - How about adding this to the end of the description section for clarity:
Note that Accesskeys are not affected because they include modifier keys.

2 - We’ve been talking about how this benefits keyboard only users as well, but there's not yet anything in the understanding about this. Proposed addition to cover that (feel free to jump in with a better example).

Addition under Benefits:
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.

Addition under Example:
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.

[mbgower]

@DavidMacDonald

If we loose "by the content" or "by the webpage", we may end up with confusion. Some may think it applies to assistive technology shortcuts, others might think its browser shortcuts.

I never saw "by the content" language. In regard to 'by the webpage", these are Web Content Authoring guidelines. Suggesting we need to put in language to keep people from misapplying it to the design of any other information or UI seems unnecessary -- and to turn 180 degrees, the degree to which it can apply to other content, we shouldn't unnecessarily restrict.

That said, if you feel it is necessary, how about :
If an author-created shortcut consists entirely of character keys, then a mechanism is available to turn it off or to remap it to include either a modifier key or other non-printing key.

if we loose "to activate a control" then we may need a definition of "shortcut"

I'm fine with a definition for shortcut.. I'd rather have that than have a definition baked into the SC that restricts a shortcut to something that activates a control. Otherwise, shortcuts that carry out actions for which there are no controls would seem to be exempt.

[DavidMacDonald]

If an author-created shortcut consists entirely of character keys, then a mechanism is available to turn it off or to remap it to include either a modifier key or other non-printing key.

We don't use "author" in any SCs currently. The WCAG 2 way has been to talk about the web page that was created by the author.

Otherwise, shortcuts that carry out actions for which there are no controls would seem to be
exempt.

It may widen the SC, I'm not sure of a non-control that could be activated, but I can live with a definition of shortcut... " have to look for a good definition.
@KimPatch
I've added your edits to the description etc..

[Ryladog]

Kim, I like all three additons. They improve the context for why the SC is needed, and is helpful to users. Thanks! Katie Haritos-Shea 703-371-5545

…

On May 15, 2017 11:57 AM, "David MacDonald" ***@***.***> wrote: If an author-created shortcut consists entirely of character keys, then a mechanism is available to turn it off or to remap it to include either a modifier key or other non-printing key. We don't use "author" in any SCs currently. The WCAG 2 way has been to talk about the web page that was created by the author. Otherwise, shortcuts that carry out actions for which there are no controls would seem to be exempt. It may widen the SC, I'm not sure of a non-control that could be activated, but I can live with a definition of shortcut... " have to look for a good definition. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#69 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFfqytFyBZdL5G_sYb9zxjzjdCUBG-KKks5r6IQHgaJpZM4K-jN2> .

[mbgower]

@DavidMacDonald

We don't use "author" in any SCs currently. The WCAG 2 way has been to talk about the web page that was created by the author.

But "author" does appear in numerous places in glossary, so I think we can make it part of the definition of "shortcut".

I'm not sure of a non-control that could be activated,

There are UIs where you may have to drill down, etc., to get to an affordance to do something. In example, if a shortcut can do something that is an item in a submenu, I'm not sure folks would think that the menu is the control being activated. Think of the gmail example, where there are no buttons or other visible controls present in the UI that match a bunch of single-key shortcuts like Archive.

[mbgower]

For a definition of shortcut, here's a first draft:

An alternative means of triggering an action by the pressing of one or more keys.

or if we want to not make it keyboard-specific

An alternative means of triggering an action, typically executed by the pressing of a combination of keys.

[DavidMacDonald]

We may want to say "keyboard shortcut" in the SC. and then use your first definition as a working definition.

But "author" does appear in numerous places in glossary, so I think we can make it part of the definition of "shortcut".

Except for one instance in the glossary, it only appears in notes for definitions. The place it appears in a definition is Programmatically determinable as "author-supplied data". So yes there is a precedence, but a thin one. I'm not sure why using "web page" in the SC is objectionable, except for just trying tighten it up. It seems to make it clearer to my eye, and is consistent with WCAG 2 formation of many SCs. I've left in "Web page" for the time being until I can see a good reason and group momentum behind the amendment.

I'm not sure folks would think that the menu is the control being activated

I'd call it a control, but we don't have a definition of control in WCAG, just user interface component, so I'm fine with leaving off "control" for the draft, and defining shortcut. I've updated the SC to drop Control.

I've updated everything to the latest, I believe.

[greg-lowney]

The latest draft wording as of 2017-05-15 reads "Character Key Shortcuts: If a keyboard shortcut consisting entirely of character keys is implemented by the web page, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-printing key. (Level A)".

On further reflection, I see no reason to limit this SC to keyboard shortcuts implemented by content rather than have it apply more broadly to all keyboard commands implemented by content. That is, if a script traps the F key and uses it to toggle between normal and full-screen modes, it is equally bad for the user whether it does so by activating a button on the page that toggles the mode (making it a shortcut) or merely toggling the mode independently of any controls (in which case it’s not a shortcut). This also lets us avoid having to define keyboard shortcuts.

However, if the keyboard command is the only way to carry out a action, then it is not acceptable for the content to merely disable the keyboard command. We can address this by adding the caveat “without loss of content of functionality” we're using elsewhere. In fact, this should probably be added in any case.

I also have three purely editorial comments: (1) We're supposed to use the term "content" rather than "web page". (2) We should standardize on either "character key" or "printing key" rather than mixing the two terms in the same to mean the same thing. While "printing key" is the one I'm more used to seeing in the past, I think "character key" is more intuitive to readers unfamiliar with the concept. (3) Although it may be overly pedantic, "entirely of character keys" actually introduces ambiguity as to whether the plural implies it must be more than one character key. To avoid that we could say "consisting entirely of one or more character keys" or "that does not include any non-character keys".

Incorporating the editorial changes alone would change it to read: "Character Key Shortcuts: 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. (Level A)"

Incorporating the change to keyboard commands alone would change it to read: "Character Key Commands: If a keyboard command consisting entirely of character keys is implemented by the web page, then a mechanism is available to turn it off or to remap it to a command that uses at least one non-printing key_, without loss of content or functionality_. (Level A)".

Incorporating both sets of changes would change it to read: "Character Key Commands: If a keyboard command 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 use at least one non-character key_, without loss of content or functionality_. (Level A)"

[johnfoliot]

The WCAG 2 way has been to talk about the web page that was created by

the author. [...]

I'm not sure why using "web page" in the SC is objectionable

Hi David, With all due respect, I think the web has advanced beyond simply the notion of a "web page", and I will argue we need to keep up as well. We also have "web apps", including "single-page apps", and other forms of Web Content (Netflix/Hulu, etc) that far transcends a "page", and so while the term "web page" may have worked 9 years ago, I hope we can recognize that "the times, they are a changing..." I will argue that *content* is in fact the correct term to be using, simply because we're working on WCAG 2.1, and not WPAG 2.1 (Web 'Page' Accessibility Guidelines) :-) JF

…

On Tue, May 16, 2017 at 12:17 AM, Greg Lowney ***@***.***> wrote: The latest draft wording as of 2017-05-15 reads "Character Key Shortcuts: If a keyboard shortcut consisting entirely of character keys is implemented by the web page, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-printing key. (Level A)". On further reflection, I see no reason to limit this SC to *keyboard shortcuts* implemented by content rather than have it apply more broadly to all *keyboard commands* implemented by content. That is, if a script traps the F key and uses it to toggle between normal and full-screen modes, it is equally bad for the user whether it does so by activating a button on the page that toggles the mode (making it a shortcut) or merely toggling the mode independently of any controls (in which case it’s not a shortcut). This also lets us avoid having to define keyboard shortcuts. However, if the keyboard command is the only way to carry out a action, then it is not acceptable for the content to merely disable the keyboard command. We can address this by adding the caveat “without loss of content of functionality” we're using elsewhere. In fact, this should probably be added in any case. I also have three purely editorial comments: (1) We're supposed to use the term "content" rather than "web page". (2) We should standardize on either "character key" or "printing key" rather than mixing the two terms in the same to mean the same thing. While "printing key" is the one I'm more used to seeing in the past, I think "character key" is more intuitive to readers unfamiliar with the concept. (3) Although it may be overly pedantic, "entirely of character keys" actually introduces ambiguity as to whether the plural implies it must be more than one character key. To avoid that we could say "consisting entirely of one or more character keys" or "that does not include any non-character keys". Incorporating the *editorial changes alone* would change it to read: "Character Key Shortcuts: 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. (Level A)" Incorporating the change to *keyboard commands alone* would change it to read: "Character Key Shortcuts: If a keyboard shortcut consisting entirely of character keys is implemented by the web page, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-printing key with no loss of content or functionality. (Level A)". Incorporating *both sets of changes* would change it to read: "Character Key Shortcuts: 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 without loss of content or functionality. (Level A)" — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#69 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c6siYJ4VxqtQrTInrBOn81aY1wAmks5r6TFSgaJpZM4K-jN2> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[DavidMacDonald]

@johnfoliot @gclowney

• I've updated it to "content"
• I added "single printable Unicode code point" to definition of Character key
• I've added "one or more" character keys,
• switched non-printing key with non-character key for consistency.

I see no reason to limit this SC to keyboard shortcuts implemented by content rather than have it apply more broadly to all keyboard commands implemented by content.

I'm not seeing the advantage of the wording here. I think of any keyboard command implemented by the content as a keyboard shortcut. Can you point me to a definition somewhere that necessitates this distinction between keyboard command and keyboard shortcut?

[KimPatch]

@DavidMacDonald
can you make these three additions to the understanding for clarity:
#69 (comment)

It looks to me like we are close.

[DavidMacDonald]

@KimPatch Done!

[KimPatch]

Here's one more example of implementing single-character shortcuts and a way to turn them off: Opera/ settings/browser/shortcut/enable advanced keyboard shortcuts.

[patrickhlauke]

Here's one more example of implementing single-character shortcuts and a way to turn them off: Opera/ settings/browser/shortcut/enable advanced keyboard shortcuts.

that's a user agent feature though, not a web content one...

[mbgower]

I'd like to help revise the Understanding doc to make it less biased towards speech recognition. Many other user groups are affected.

[mbgower]

@kwahlbin, I put my hand up on today's call to help make the Understanding doc more broad and less speech focused. Specific asks included more explanation on the use of modifier keys, and focusing on other users groups: keyboard users, low vision, cognitive.
Let me know if you want me to go ahead and just make a draft, or if there's a process you want me to follow.

[kwahlbin]

@mbgower If you would like to write the changes to the understanding, I would be happy to incorporate this into the understanding doc.

[KimPatch]

Adding this Email reply to survey comment https://www.w3.org/2002/09/wbs/35422/character-key-issue69/results just keep everything in one place:
Jason's comment:

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. This working group should investigate (via horizontal review from the ARIA Working Group or discussion with speech technology developers, especially those who have implemented ARIA already) whether platform accessibility APIs can be used, or adapted, to fill this need.

Two things :

First, solving the single character shortcut problem by not forwarding dictated text doesn't work for people who have mobility issues and might accidentally hit single character shortcuts. Other user groups will benefit from the ability to turn off or change single character shortcuts too.

Second, I can say from long experience with speech recognition as my main and for a time my only means of input (Kurzweil, ViaVoice, the original DragonDictate, Dragon NaturallySpeaking, MacSpeech Dictate, Mac Dragon, Windows Speech Recognition, and native Mac speech recognition) that this not a good path to go down. Whenever a speech input company has tried to limit areas that the user can send keystrokes by speech, users have been frustrated because it's too hard to anticipate what users will want to do. It’s too prescriptive and limiting (I previously mentioned the example of speech users being frustrated because they couldn’t use Dragon’s spell command to go through menus several steps at once). It is important to let speech users do anything the keyboard user can do.

Letting speech users do anything the keyboard user can do generally works really well – with the exception of single character shortcuts. This proposed solution - to allow the user to turn off or change the shortcuts – is intuitive. I've had many users ask me how to turn off or change single-character shortcuts. I have a good answer for them if it's Gmail or WordPress. Not so much if it's Twitter.

I think it would cause a bigger problem trying to solve this one by taking away the ability for users to do anything a keyboard user can do. If I can change single-character shortcuts I can use the changed shortcuts or call them in speech macros. If Dragon decides for me that my means of input should ignore these I can’t get to them at all. Here’s a use case: I need to be able to test anything on my computer using speech input – including single key shortcuts that are good for keyboard users. I just need the ability to control them – to turn them off when I'm not testing, or even better to change them to something more appropriate for the mix of input I use on the computer.

[KimPatch]

Adding this reply to https://www.w3.org/2002/09/wbs/35422/character-key-issue69/results survey:
Oliver Keim's comment:

Character Key Shortcuts help to improve keyboard efficiency very much and is used on a number of standard web UIs, like GitHub, Confluence, etc. It would be a huge drawback for keyboard-centric users. 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).

Agreed that character key shortcuts are great for keyboard users. This SC doesn't change character key shortcuts for keyboard users. It just gives users a way to turn them off or change character key shortcuts. This is important for several types of users, including mobility impaired users who may accidentally hit single keys and speech users, whose currency is strings of letter keys.

[joshueoconnor]

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]

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]

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]

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 ***@***.***> 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 <#69 (comment)>, 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]

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]

@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]

@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]

Merged with editor's draft.