CARVIEW |
Navigation Menu
-
Notifications
You must be signed in to change notification settings - Fork 55
Speech Input #68
Description
Current versions of SC and Definitions
SC Shortname
Accessible Name
SC Text
Where an active control has a visible label, the accessible name for the control includes the text string used for its visible label.
Suggestion for Priority Level (A/AA/AAA)
Level A
Related Glossary additions or changes
Accessible Name
The accessible name is the name of a user interface element. The value of the accessible name may be derived from a visible (e.g., the visible text on a button) or invisible (e.g., the text alternative that describes an icon) property of the user interface element. A simple use for the accessible name property may be illustrated by an "OK" button. The text "OK" is the accessible name. When the button receives focus, assistive technologies may concatenate the platform's role description with the accessible name. For example, a screen reader may speak "push-button OK" or "OK button".
Based on Definition of Accessible name https://www.w3.org/TR/accname-aam-1.1/
What Principle and Guideline the SC falls within.
Principle 2: Operable
New Guideline: Speech
Description
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.
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.