Rework 2.1.4 Character Key Shortcut understanding - #5336
Conversation
* expand the focus to not be primarily about speech users * expand the speech input explainer to match reality a bit better * remove the outdated resources section
❌ Deploy Preview for wcag2 failed.
|
…cter-key-shortcuts-rework' into patrickhlauke-character-key-shortcuts-rework
…keyboard key" section
94f67f4 to
2942012
Compare
| <p>A user interacting with a web page or web app that doesn't use single-character shortcuts doesn't have this problem. Inadvertent strings of characters from the speech application are not interpreted as shortcuts if a modifier key is required. A speech user filling in a text input form may find that a phrase that is accidentally picked up by the speech microphone results in stray text being entered into the field, but that is easily seen and undone. The Resources section of this page contains links to videos demonstrating these types of issues.</p> | ||
| <p>Speech input users generally work in a single mode where they can use a mix of dictation and speech commands. 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, such as "the small boat", then pause, and say a command to delete that dictation, such as "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 (i.e., "the small boat delete line").</p> | ||
| <p>In most cases, voice control/speech recognition software is "context-aware" – speech is not interpreted as dictation, unless focus is on a form control or field that accepts keyboard input. Otherwise, speech is only interpreted as a command. In addition, even when focus is inside a form control or field that accepts keyboard input, dictation does not generate "faked" synthetic key presses – the spoken text is generally injected directly into the relevant form control/field. Synthetic key presses only happen when a user gives an explicit command, such as "Press X key".</p> | ||
| <p>However, there are some voice control/speech recognition programs (such as <a href="https://talonvoice.com/">Talon Voice</a>) that are not "context-aware". All speech is interpreted as either a command or dictation, regardless of where the current focus is. In addition, saying certain keywords is interpreted by some programs as a shorthand for the "Press … key" command, leading to potential unintentional single key presses. Critically, programs that are not "context-aware" may also turn dictation into synthetic key presses, meaning that an unintentionally spoken word can become a sequence of single-key commands if the cursor focus happens to be in the wrong place. Character key shortcuts will be problematic for users of these non-context-aware programs.</p> |
There was a problem hiding this comment.
Reference to Talon Voice: How long will that be valid? Leave out brand name?
There was a problem hiding this comment.
the issue here is that it seems Talon is pretty much the only tool out there that behaves this way it seems...this is a way to salvage the whole voice angle, in my view, as none of the other voice control/voice access tools commonly used now have the problem this SC purports to solve...
There was a problem hiding this comment.
I agree with Detlev, I would not get as far as naming a specific software here
|
|
||
| <h3>Keyboard use with screen readers</h3> | ||
| <p>The behavior or screen readers when it comes to keyboard interactions, and whether or not key presses are passed on to web content, varies depending on the specific platform and screen reader used.</p> | ||
| <p>On Windows, screen readers such as Jaws, NVDA, and Narrator generally intercept all key presses, as many of the shortcuts to control screen readers use single keys. Key presses are then only passed on to web content depending on the context. For instance, if focus is on a <code>button</code> element, only <kbd>Space</kbd> and <kbd>Enter</kbd> key presses (and a few generic keys, such as <kbd>Tab</kbd>) will be passed to the web content – any other key presses will be "swallowed" by the screen reader. This behavior is overridden in HTML when elements have a <code>role="application"</code>, or are children of an element with that <code>role</code>. In general, character key shortcuts won't be problematic for Windows screen reader users, as it's unlikely that they'd accidentally trigger a shortcut.</p> |
There was a problem hiding this comment.
Good stuff - but the general concern is that all this is fairly specific and might change any time, thereafter being either wrong or needing to be updated. (Will we? How soon?)
I wonder whether acceptance of single keystroks should be linked to the SR mode (browse of forms mode) rather than highlighting role application - not sure. You have done all the research...
There was a problem hiding this comment.
we either get specific, or we generalise and give the wrong impression (as the current understanding does ... it makes it sound like the problem described happens in all voice access/control scenarios, but it's actually only when using niche software). so the same problem may happen here, if we just generalise it as "in some cases this is a problem").
in this case, i'd rather be more specific, than pretending that things are a general issue/problem when they're not.
There was a problem hiding this comment.
Noting that role="application" is used in frequently-used apps such as gmail, so can seem common.
|
|
||
| <h3>Keyboard use with screen readers</h3> | ||
| <p>The behavior or screen readers when it comes to keyboard interactions, and whether or not key presses are passed on to web content, varies depending on the specific platform and screen reader used.</p> | ||
| <p>On Windows, screen readers such as Jaws, NVDA, and Narrator generally intercept all key presses, as many of the shortcuts to control screen readers use single keys. Key presses are then only passed on to web content depending on the context. For instance, if focus is on a <code>button</code> element, only <kbd>Space</kbd> and <kbd>Enter</kbd> key presses (and a few generic keys, such as <kbd>Tab</kbd>) will be passed to the web content – any other key presses will be "swallowed" by the screen reader. This behavior is overridden in HTML when elements have a <code>role="application"</code>, or are children of an element with that <code>role</code>. In general, character key shortcuts won't be problematic for Windows screen reader users, as it's unlikely that they'd accidentally trigger a shortcut.</p> |
There was a problem hiding this comment.
A thorough explanation of browse mode vs. focus/forms mode seems necessary to me
There was a problem hiding this comment.
browser mode vs focus mode does not change how it behaves with regards to passing key events to the page though, so not sure it's necessary?
There was a problem hiding this comment.
As to browse mode, I assumed for a second that things like SR single character shortcuts (e.g. "h" to jump to headings) would not work in forms mode, but it is in fact only when focus is on text input elements or selects that the shortcut is not passed to the AT - with selects even when the character does not match the start of any select option.
There was a problem hiding this comment.
well, since the section is about screen reader I believe that this deserves at least a mention. At the same time, browse mode can be turned on manually (not a likely scenario, but it can be done) even when a specific component is currenlty focused
There was a problem hiding this comment.
the shortcut is not passed to the AT
just a quick note that it's the other way around: AT sits between the keyboard and the browser. any keypresses are either consumed by the AT, or passed on to the browser (not the other way around)
Co-authored-by: Baldino Morelli <baldino.morelli@usablenet.com>
|
|
||
| <h3>Keyboard use with screen readers</h3> | ||
| <p>The behavior or screen readers when it comes to keyboard interactions, and whether or not key presses are passed on to web content, varies depending on the specific platform and screen reader used.</p> | ||
| <p>On Windows, screen readers such as Jaws, NVDA, and Narrator generally intercept all key presses, as many of the shortcuts to control screen readers use single keys. Key presses are then only passed on to web content depending on the context. For instance, if focus is on a <code>button</code> element, only <kbd>Space</kbd> and <kbd>Enter</kbd> key presses (and a few generic keys, such as <kbd>Tab</kbd>) will be passed to the web content – any other key presses will be "swallowed" by the screen reader. This behavior is overridden in HTML when elements have a <code>role="application"</code>, or are children of an element with that <code>role</code>. In general, character key shortcuts won't be problematic for Windows screen reader users, as it's unlikely that they'd accidentally trigger a shortcut.</p> |
There was a problem hiding this comment.
Noting that role="application" is used in frequently-used apps such as gmail, so can seem common.
Co-authored-by: Alastair Campbell <ac@alastc.com>
Co-authored-by: Kenneth G. Franqueiro <kfranqueiro@users.noreply.github.com>
Co-authored-by: Bruce Bailey <bruce@bailey4.us>
6 participants
Stretch goals (to discuss with TF):
Closes #953
Preview:
Diff: