Proposed Speech Input

From Mobile Accessibility Task Force

Note

Note to working group: Note email thread about SC 3.3.2 and 1.3.1 http://www.w3.org/mid/BD8954E0-4D11-4357-9BB4-2766FE7D9DC9@raisingthefloor.org

2016-11-17 Discussion: https://www.w3.org/2016/11/17-mobile-a11y-minutes.html

2016-09-08 Discussion (This discussion is more about a previous version of this SC, which is now in the boneyard section below): This is covered in 2.2.1 and #5 Conformance

This is redundant to those, but maybe use the speech examples in this to strengthen 2.2.1.

This shares an issue with autopopulate: autopopulate field not through keystrokes so validation doesn't work

Proposed SC Shortname

Speech Input

Proposed SC Text

All functionality of the content does not obstruct a user’s ability to access the commands through speech input.

Suggested Glossary additions or changes

None

Associated Principle and Guideline *or* proposed Guideline the SC falls within

Principle 2: Operable New Guideline: Speech Level A

Proposed SC Intent

One means of speech input is speaking menu, link and button labels that appear on a webpage. Speech input programs sometimes enable users to speak labels that are not seen on the page. Speech users can accidentally say a word in a hidden label and be taken to that link without knowing what has happened. Mismatched labels can also confuse speech users when they say what they can see, but this does not match the actual command.

Single key shortcuts can also obstruct speech input – this is addressed under SC M12a and M12a.

Another important means of speech input is speaking keyboard controls. This is addressed under 2.2.1. Detail specific to speech input users: Users can speak keyboard controls or write custom speech commands that can call keyboard controls. Making sure that keyboard controls are available to speech input users ensures that, in general, anything that is accessible by keyboard is accessible by speech. Some speech users' may use a mix of inputs or have colleagues who use keyboard input. Mapping speech to keystrokes ensures that the same mental map can be used for both types of commands.

Proposed SC Examples

A speech input user is buying a gift on a website. The user is adding a note to his nephew when he utters the word "time" and is suddenly whisked off to another website, losing the information she entered because a hidden label link on the page contains the word "time". The user doesn't know what has happened, and tries again. This time he is more careful in writing the note and so speaks in short phrases. This invariably causes him to say the single word "time" again, which starts him on another loop. Despite going through this loop several times he doesn't have the information to figure out what has happened because the hidden label is not discoverable.

A speech input user tries to click a button labeled "submit" by saying "submit", but it does not respond. This is due to a mismatched label, but the user cannot see the mismatch and so does not know why this particular button does not respond. After trying to click the button by saying the label several times, she falls back to having to say several commands to move the mouse and click the button instead. The next time she uses the site she remembers that the site doesn't work well with speech, but doesn't remember which button doesn't respond.

Proposed SC Benefits

Speech input users will have fewer surprising changes of focus and will be able to easily activate controls on the page.

Testability

Identify all controls on the page. Review underlying code and note the accessible names provided for the control. Ensure that the visible label and the accessible name contain the same text.

Techniques

Ensure that visible labels match hidden labels.

Resources

Boneyard

Previous versions

__________

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:

Users can also write custom speech commands that can call keyboard controls. Making sure that keyboard controls are available to speech input users ensures that, in general, anything that is accessible by keyboard is accessible by speech. Some speech users may also use a mix of inputs. Mapping speech input to keyboard controls keeps cognitive load down because these two input methods can be accessed using the same mental map for commands. Some speech users' may have colleagues who use keyboard input. Mapping speech to keystrokes ensures that colleagues can use the same mental map for commands.

Examples:

A speech input user is trying out an unfamiliar program that does not yet have native speech commands. Rather than having to write native speech commands before trying out the program to see if it will be used enough to warrant writing the custom commands, the speech user looks up keyboard commands and says things like "Press Control F" to check out the Find function of the program.

A speech input user is writing a macro to enable a native speech command. The macro language includes all possible keyboard shortcuts. This allows the speech input user to fully enable the program for use with speech input because the user is able to map any control or series of controls to a speech command.

Keyboard resources that are no longer necessary

Referenced from #aria-touch

Guide

  1. Success Criteria Text: If suggesting a wording change to an existing success criteria, write the complete SC text and indicate the changes by surrounding new text with "@@". For example (just an example), "1.4.3 Contrast (Minimum): The visual presentation of @@text, images of text, and icons@@ has a contrast ratio of at least 4.5:1, except for the following: (Level AA)".
  2. Success Criteria Level: A/AA/AAA
  3. Glossary: Suggested glossary definitions or changes.
  4. Associated Principle and Guideline or Proposal for New Guideline
  5. Success Criteria Intent: What users benefit from the content successfully addressing it.
  6. User benefits: Clear information about how the proposal will benefit users, along with justification and evidence of the benefits. Include links to research.
  7. Test Procedure: Description of how this SC can be tested.
  8. Technique Titles: Possible technique titles which could be used to satisfy the SC.
Retrieved from "https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/index.php?title=Proposed_Speech_Input&oldid=3867"