|
|
|
|
|
Multi-state Components
Last Updated:
Guideline
For all user interface components (including but not limited to: form elements, links, and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
Intent
The intent of this regulation is to ensure that Assistive Technologies (AT) can gather information about, activate(or set) and keep up to date on the status of user interface controls in the content.
When standard controls from accessible technologies are used, this process is straightforward. If the user interface elements are used according to specification the conditions of this provision will be met.
If custom controls are created, however, or interface elements are programmed (in code or script) to have a different role and/or function than usual, then additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies.
A particularly important state of a user interface control is whether or not it has focus. The focus state of a control can be programmatically determined, and notifications about change of focus are sent to user agents and assistive technology. Other examples of user interface control state are whether or not a checkbox or radio button has been selected, or whether or not a collapsible tree or list node is expanded or collapsed.
Finding Applicable Components
- Identify interface components that have multiple states; such as open, closed, expanded, checked, etc.
Inspecting and Using Components
- Activate the JAWS screen reader.
- Navigate to each interface component that has multiple states and using the keyboard, toggle the component through each applicable state.
- Validate that JAWS successfully identifies the changed state.
Section 508/WCAG 2.0 Failure Conditions
A multi-state component does not reveal its current information:
- Fails 1194.31(a): Use without vision.
- Fails 1194.31(b): Use with low vision.
- Fails 1.3.1 Info and Relationships
- Fails 4.1.2 Name, Role, Value
Reporting Test Results
- Any failure in Section 508 Failure Conditions results in: Fails Baseline Requirement #6.
- Multi-state components reveal their current information (Name, Role, and/or State) then: Passes Baseline Requirement #6.
See Also |