Speech Input Accessibility (Guideline 2.7)
- 1 1. Proposed Guideline 2.7: Make it practical for speech input users to operate all functionality 2016-03-04
- 2 2. Additional issues for discussion
- 3 3. Resources
- 4 David's crack at SCs
1. Proposed Guideline 2.7: Make it practical for speech input users to operate all functionality 2016-03-04
Proposed SC's 2016-03-04
2.7.1 Speech Input: All functionality of the content (including touch and gesture) is operable through the keyboard, and does not obstruct a user’s ability to access the keyboard commands through speech input. (Level A)
Understanding: One means of speech input is speaking keyboard controls. Users can also write custom speech commands that can call keyboard controls. This means that, in general, anything that is accessible by keyboard is accessible by speech.
2.7.2 Single key shortcut alternative: The user can adjust any single key shortcut to an alternative control of a string of symbols and letters.
Understanding: While using single letter keys as controls might be appropriate and efficient for keyboard users, single key shortcuts are disastrous for speech users, who can inadvertently set off multiple controls by speaking a single phrase. To avoid excluding speech users, single key shortcuts must be accompanied by a mechanism that allows the user to customize single key shortcuts. For example, the user could change the single key shortcut “r” for reply to “+r” or to “This Reply”.
2. Additional issues for discussion
- Issue: hidden text as speech command is misguided, and a showstopper for practical use. You really need another channel for speech commands, it doesn’t work overloading descriptive text. Not sure we can do much about this one.
- Issue: data masking technique from Kathy (this really should be solved at the platform/input level - this is an issue of the speech program not being able to sense what the user wants, so it shouldn’t.. This is also a showstopper for practical use).
- Issue: Tower of Babel – see Google speech commands, which are slightly different from Dragon PC commands, which are much different from Dragon Mac commands – possible solution is the user can change any speech shortcut. This is also the solution to single key shortcuts. You need another channel for speech commands, it doesn’t work overloading regular keyboard shortcut command because you may have different people using the same computer or one person using two different input methods.
- Bottom of chart has four levels of VoiceOver keyboard commands: VoiceOver Command Charts
- Jonathan's ARIA page lists issues related to keyboard access in addition to other ARIA information: Test Results: ARIA mobile browser support
- Patrick: Google doc where we documented some of the areas where ARIA patterns fall apart on touch devices and in mobile+keyboard scenarios: areas where ARIA patterns fall apart on Touch/Mobile plus keyboard
David's crack at SCs
Possible new SC
Customized shortcut keys: Each customizable keyboard shortcut on the web page allows for a string of up to 20 characters to be assigned to the shortcut.
Speech users can inadvertently activate custom controls by simply dictating a phrase on the page that contains a letter that has been assigned to a custom control. This requirement allows them to assign a phrase to the shortcut and reduces the possibility of accidental activation significantly.
Possible new SC
Turn off shortcuts: If shortcut keys are used on the web page, a mechanism is available to turn them off.
Speech users can inadvertently activate custom controls by simply dictating a phrase on the page that contains a letter that has been assigned to a custom control.