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 https://github.com/w3c/wcag21/issues/69#issuecomment-275535951

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

Thanks for asking about that. The third technique (see above) suggests allowing speech input users to remap to up to 25 characters, which is what is needed to allow speech Input users to create commands that work across speech engines – the equivalent of remapping keys for keyboard users. I was thinking it would be good to put this into the SC at first as an option instead of the non-printing key option, but really we need both because we need the non-printing key option for keyboard users. So it's not an "or", it's an "and". This raises the bar for speech input users to get native commands, but I think it's the right way to do it, because we don't want to create something that leaves out keyboard users who have trouble with single key shortcuts.

[DavidMacDonald]

OK so their are 3 things to address in your latest draft.

• is "printable characters" or "character keys" or "alphanumeric keys" best
• Add the 25 printable option
• address exceptions for keys that don't activate the control unless the component has focus (dropdowns etc)

I think this covers the three outstanding issues:

Shortcuts

If a shortcut consisting entirely of character keys is implemented by the web page to activate a control that does not have focus, or to activate a control in a component that does not have focus, then a mechanism is available to do one of the following:

1. turn it off
2. remap it to a shortcut that uses at least one key that is not a character key
3. remap it to a shortcut that uses up to 25 character keys.

Character key: any keyboard character that is printable, i.e. letters of the alphabet including capitals, punctuation, numbers, and symbols.

[KimPatch]

Thanks – I'm thinking we should stick to character keys because this covers punctuation. The 25 printable option is already there as the third technique. Is anything else needed for that? Understood – Understanding language that makes it clear that this doesn't include drop downs etc.

[KimPatch]

Here's the video example I promised. How single key shortcuts affect speech input This video shows how a single word or phrase can trip several single key shortcuts at once in Google Docs. There are two examples. The first one, a single word, opens the information dialog box and opens a Google drawing in a new window. The second one, a short phrase, opens the information dialog box, opens a drop-down, and changes the document list from a list to tiles. https://youtu.be/xzSyIA4OWYE

[DavidMacDonald]

The 25 printable option is already there as the third technique. Is anything else needed for that?

I'm not sure I understand... is this what we want?

[jnurthen]

@KimPatch What speech software are you using on that video? I can't reproduce any of these issues on (for example) twitter. I can't find any way with Dragon (on windows) to get the J and K shortcuts for moving up/down tweets to fire when speaking words. Are there settings I need to modify in order to get this to happen?

[mbgower]

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.

Any concerns with internationalization quoting the ASCII set? Great for a cross reference, and I feel like we can work printable characters into the definition of "character". I still feel like "character" is more graspable as a concept without putting "printable" in front.

[KimPatch]

@jnurthen Dragon 15 Pro individual, Firefox 53 and Chrome 57, Windows 7 Pro (It works this way whether or not I have HTML support enabled, whether or not I have the Dragon plug-in enabled, and whether or not I have the dictation box enabled.) Can you reproduce the Google Docs example?

[mbgower]

remap it to a shortcut that uses up to 25 character keys

Either I'm not getting this, or it feels like you are trying to make it a requirement that authors support the creation of macros by speech developers. Historically, speech engines have used the keyboard affordance which we guarantee with 2.1.1, or they have used the programmatically associated label.

[KimPatch]

@DavidMacDonald @mbgower Here's what I'm thinking:

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. Technique: I think we should leave the mention of 25 character keys as the third technique – see above in the original SC Understanding: Language about menus needs to be added to understanding – I'll have that shortly

[jnurthen]

@KimPatch Google Docs is an incredibly complex web app and I am not surprised that there are potential issues when using it. However, I don't want to bar single key shortcuts on all web sites if that is not an actual issue on simpler sites.

My understanding of how speech recognition works on web sites is that you can only dictate into areas which are recognised as areas which support text input. If you force dictation into other areas and you have the dictation box set to simulate keystrokes then I can see how this could happen - but that doesn't sound like a sensible configuration to me.

I would really like to know if you can trigger the up/down key strokes accidentally (J and K) on twitter or on facebook to understand whether it is single keys that are the issue or something else.

[KimPatch]

@jnurthen Yes this happens everywhere including Twitter. I'm using Dragon commands "Press J" and "Press K" to test the single keys, and words that contain those letters also trip them, which is what causes the problems. Here's an example of a word tripping a couple of single character key shortcuts at once on Twitter: https://youtu.be/OPjfpDU9S08

(The dictation box doesn't engage here whether the option is turned on or off. You can dictate anywhere using Dragon and that's the way it needs to be, because you have to dictate commands as well as text. If the dictation box option is enabled and Dragon senses that a text field is not fully supported by Dragon, meaning the user won't have access to the advanced correction commands like "select XYZ" that select words anywhere on the screen and so require Dragon to keep track of where all the words are, it opens the dictation box, which fully supports all these correction commands. The idea is that you can dictate into the dictation box, with access to better correction commands, then paste into your application when you're done. So the dictation box can sometimes intercept keystrokes if it's on. But this is generally an annoying way to work so most users turn it off.)

[KimPatch]

@DavidMacDonald @mbgower Here's the paragraph I propose adding to the Understanding text to address menus, drop downs etc.:

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.

[patrickhlauke]

Here's an example of a word tripping a couple of single character key shortcuts at once on Twitter: https://youtu.be/OPjfpDU9S08

i asked this very early on in our discussions, but: isn't this arguably an AT issue, rather than something related to what authors should and shouldn't do? would a more universal solution to the problem not be for Dragon not to trigger/send keystrokes when not focused on an form control/editable field unless explicitly instructed to do so (either prefixing with a "Press..." or similar)?

[KimPatch]

@patrickhlauke I know it may be counterintuitive, but it really can't be solved in the AT. Speech input users need to be able to send keystrokes anywhere that keyboard users can. (The little bit of limitation along these lines that Dragon has tried has caused problems. Dragon had a spell command that you could use to say, for instance, "Spell f a" to return "fa" that they didn't enable to be used in menus. The spell command was always being reported as broken because users tried using it in menus because they wanted to go through two layers at once this way. Probably the most interesting thing about it was even if you knew you couldn't use the spell command in menus, you'd find yourself using it because it was habit. So the best solution was to abandon the spell wording, make a set of commands that worked in both places and make that one habit instead.) This is also relevant for users with mobility problems. So there are two populations that benefit from being able to turn off this specific type of command that's great for some keyboard users but a disastrous trap for others.

[patrickhlauke]

i'm not saying you should be forced to spell every single character. what i am saying is that AT could behave in a similar way to screen readers and their document/forms mode, including auto-switching in and out of those modes. if focus is on a form control, send all spoken letters/words as keystrokes. if not focused on something that generally accepts keystrokes/is editable, user explicitly toggles this (e.g. prefixing their sentence with "Type..." or similar for words, or "Press..." for single keystrokes).

[KimPatch]

Ah, but Dragon users need a mix of text and commands in text boxes – really, pretty much everywhere. For instance, I need to be able to edit as I write, so I need to be able to say commands like "Backspace 2" and "Delete Line" in this text box. The difference between dictation and commands is just where you pause. I was able to easily write those two commands up there as text because I didn't pause right before and right after the commands. This works well, and much better than modes. In the early days of speech input there was a lot of experimentation with modes for commands and dictation and they were largely abandoned. Dragon does have to predict homophones, for instance "five" or "5", and is not particularly good at it, so I use "five long" and "five short" if I want to be sure to return the right form. Same with symbols: ampersand versus &. Having to think about this is a noticeable cognitive load. Increasing explicit toggles would be adding a lot to cognitive load, and it's largely unnecessary. It's just character key shortcuts that present a problem, and it's a straightforward fix to turn them off, and a fix that will also benefit mobility impaired keyboard users. I guess the spell illustration wasn't clear – my point was Dragon prevented text in menus assuming users only needed commands in menus, and users realized it was more efficient to use text, so that was an auto switching fail.

[patrickhlauke]

For instance, I need to be able to edit as I write, so I need to be able to say commands like "Backspace 2" and "Delete Line" in this text box.

and as I said, once focus is in anything that is editable/a form control, the AT could carry on behaving as it is behaving now, since sites that use keyboard shortcuts (if they're coded correctly of course) will not trigger their custom commands once a user is in a form control.

so the behavior i described above would simply happen when focus is somewhere else in the page, like on a link, which is not an editable element.

[KimPatch]

@patrickhlauke Mouse users automatically focus everything they do. Speech users, and to some extent keyboard-only users, are much more prone to user error when the focus is not where the user expects it to be.

Single character key shortcuts greatly multiply this effect. For keyboard only users with mobility issues, single character key shortcuts are easier to accidentally hit than multi-key shortcuts. For speech input users single key shortcuts are not only easy to hit accidentally (e.g. you say something you shouldn't when the focus is in the wrong field) but you can hit a whole bunch of them at once, and sometimes it's very difficult to track down the string of things that have been done and undo them.

In terms of how likely Speech input users are to be affected by this issue, I like to use the metaphor of having a 10-foot-deep hole in the middle of a conference room and telling people to just avoid it rather than putting a railing around it. It's obvious that this is not good because at some point someone's going to fall in.

Even though I've been using speech input for a long time, if I'm using a program that has single character key shortcuts I know something's likely to happen to trip a string of them at some point. For one of any of a half-dozen reasons, I'm going to think the focus is somewhere it's not, or I'm going to think the microphone is off when it's not, and I or someone else is going to say a phrase that the computer will then interpret and I will have to unravel. Keeping vigilant enough to avoid this most of the time drains brainpower.

For less experienced users it's much worse. Something goes wrong and they don't know what happened, sometimes even if they’re aware they are on a webpage that uses single character key shortcuts. I've many times had to explain that it's not actually broken, it's just accidental activation of single character key shortcuts.

[mbgower]

Here's the cleaned up version I proposed on the just-finished call:

If a shortcut only consists of one or more printable character keys, then a mechanism is available to turn it off or to remap it to a shortcut that includes a modifier key

In terms of Greg's concerns about Esc, PgUP and F10, those are not printable characters, so this wouldn't apply. Spacebar and Enter (line break) are oddities we'd need to clear up in understanding doc. I don't consider those printable characters, but I get how you could argue that someone would think so

[mbgower]

Here's the same basic thing, using some of Kim's language from prior comments:

If a shortcut consisting entirely of character keys is implemented to activate a control, then a mechanism is available to turn it off or to remap it to a shortcut that includes a modifier key

However, I find "activate a control" is a little overly prescriptive, and overall a bit wordier, so maybe...

If a shortcut consists entirely of character keys, then a mechanism is available to turn it off or to remap it to a shortcut that includes a modifier key

[Ryladog]

I like it, but I would add custom….

If a shortcut consisting entirely of character keys is implemented to activate a custom control, then a mechanism is available to turn it off or to remap it to a shortcut that includes a modifier key

​​​​​ katie

Katie Haritos-Shea Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)

Cell: 703-371-5545 | mailto:ryladog@gmail.com ryladog@gmail.com | Oakton, VA | http://www.linkedin.com/in/katieharitosshea/ LinkedIn Profile | Office: 703-371-5545 | https://twitter.com/Ryladog @ryladog

NOTE: The content of this email should be construed to always be an expression of my own personal independent opinion, unless I identify that I am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - that my personal email never expresses the opinion of my employer, Deque Systems.

From: Mike Gower [mailto:notifications@github.com] Sent: Thursday, May 11, 2017 12:54 PM To: w3c/wcag21 wcag21@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [w3c/wcag21] Single key shortcut alternative (#69)

Here's the same basic thing, using some of Kim's language from prior comments:

If a shortcut consisting entirely of character keys is implemented to activate a control, then a mechanism is available to turn it off or to remap it to a shortcut that includes a modifier key

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/69#issuecomment-300850823 , or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqytJF31TowgUUvzZ8UPtJTT_7Cxtmks5r4z0vgaJpZM4K-jN2 . https://github.com/notifications/beacon/AFfqymMRL3_K9lBFXq_gJ55g_49C9E5Cks5r4z0vgaJpZM4K-jN2.gif

[mraccess77]

Ø I like it, but I would add custom…

I’m not sure why it matters if it’s a custom control or a standard control.

Jonathan

[mbgower]

If a shortcut consisting entirely of character keys is implemented to activate a custom control, then a mechanism is available to turn it off or to remap it to a shortcut that includes a modifier key

I’m not sure why it matters if it’s a custom control or a standard control.

Yes, @mraccess77 , that's why I'm inclined to take out the part that I've bolded in Katie's suggestion. I wasn't sure it should be confined to custom controls either. @Ryladog , one could still assign a problematic shortcut to a standard control, couldn't one?

Thus my suggestion:

If a shortcut consists entirely of character keys, then a mechanism is available to turn it off or to remap it to a shortcut that includes a modifier key