2.4.11 Character Key Shortcuts, other cases?

[StommePoes]

The current SC has, users can either

• turn off
• remap
• only works per focussed component

I was thinking of Twitter for this case. David's site mentions

Users of speech technology. (e.g., If the site hijacks "p" key for shortcut, when the user dictates words such as "happy" the shortcut can be triggered.)

So when using WSR or Dragon 13 on for example Twitter I have not had this issue: when I'm NOT focussed on a control, if I say "press n" I can trigger the shortcut for writing a new tweet, however once in a dictation mode the "n"s do not continually trigger more new tweets (neither does typing them of course).

For Twitter to conform their easiest recourse would be an "off" button in the settings, since it's a login style site. However it seems to make sense that the listener for the "n" key is apparently only active when I'm NOT focussed in a typeable field (if it did, it would break for everyone). The third possibility

Active only on focus
The keyboard shortcut for a user interface component is only active when that component has focus.

wouldn't make sense for any shortcut key actions that weren't component-based (page-wide navigation, bringing up features normally activated from within menus or buttons, etc). But it seems any "interface components" that deal with text can never have a shortcut anyway, not for speech users but anyone, because people aren't commanding inside input fields, they're typing. Those never make sense.

So my question is really, should this be an author thing because some dictation softwares confuse when they're dictating and when they're commanding, or is this something dictation software should adhere to (that when in dictation mode, it has a clear-to-users way of switching to commands). Dragon seems to rely on pauses of some length before trying to match to a command. Or does it matter on the type of event listener the author uses? Is Twitter for example doing listeners in a way that allows single-character command shortcuts that simple dictation (and typing) don't trigger? Is it because those listeners are being disabled whenever the user is in any type of text-oriented interface component and if so couldn't that be a success bullet point?

I'm assuming the example case on David's page has happened and does happen to speech users but I'd love to know if there's a webpage that can reproduce that in order to maybe make a better delineation between what should authors do and expect vs what's the responsibility of the dictation software.

[KimPatch]

@StommePoes
It looks like you're testing this where the single key shortcuts aren't active.

In the Character Key Shortcuts Understanding
https://rawgit.com/w3c/wcag21/character-key-shortcuts/understanding/21/character-key-shortcuts.html document under "Resources" near the bottom
Take a look at the second video example. Here's the direct link. There's also some explanation text.
https://www.youtube.com/watch?v=OPjfpDU9S08
This shows how easily things can go wrong for a speech user in Twitter.
The first video shows something similar with Google docs. I've experienced these myself and watched them happen to users.

If you want to re-create the Twitter example, click on a post, then say a word like Nelly or James and then try to figure out what happened and what you should reverse (If you want a bigger challenge, say a whole phrase, or click on a post with a lot of comments that go below the screen so you have to scroll to see what might've happened).

This happens regularly to speech users wherever there are single key shortcuts. It happens to users who are experienced both in using speech and and using the programs that contain single key shortcuts if they can't turn off or remap the shortcuts and have to use the sites. It also prevents people from using speech on certain sites, or using certain sites if they must use speech. When inexperienced speech users run up against this they often have no idea what has happened.

Here's a github example I've experienced several times: the single key shortcut "s" jumps the cursor to the search box at the top of the page. If I don't notice where the focus is and I'm thinking I'm dictating into the text box, or someone comes into my office talking too loudly before I can turn off the microphone if Dragon (15) hears something that contains an "s", I've lost my place.

So my question is really, should this be an author thing because some dictation softwares confuse when they're dictating and when they're commanding, or is this something dictation software should adhere to (that when in dictation mode, it has a clear-to-users way of switching to commands).

In the understanding document under "Heading" there's a detailed explanation of how speech users commonly work. Modes are very rarely used because they are so inefficient.

[StommePoes]

Thanks for the response Kim!

[awkawk]

Thank you for commenting. For more information about how the AG WG will process this issue, see the following:

• Issue Processing - How the WG will discuss the issue
• Issue Resolution - Identifying and responding to the official WG response
• Issue Notification - How to limit notifications from GitHub

[awkawk]

@StommePoes Does the information Kim provided answer your question?

[StommePoes]

@awkawk yes it does! I was not certain if I could close this myself or if someone else needed to close it.

[awkawk]

Thanks!