Summary
The use of ARIA roles, states and properties is necessary to ensure that custom controls are accessible to users of assistive technologies.
Techniques
-
Enable interaction using roles, states and properties. [[WCAG-4.1.2]]
-
Ensure ARIA roles, states and properties are valid on their specified elements. [[WCAG-4.1.1]]
-
Ensure all parent/child role requirements are satisfied. [[WCAG-4.1.1]]
-
Do not trigger events when a control recieves focus. [[WCAG-3.2.1]]
-
Do trigger unexpected events when a user inputs values or changes settings. [[WCAG-3.2.1]]
Example
Explanation
Although HTML provides a number of native controls (e.g., input
, button
,
progress
), developers often have to create their own equivalents to avoid the
styling limitations or introduce specialized functionality.
The creation of custom controls can cause seriously accessibility issues, however, as the reliance on JavaScript to make the functionality work does not translate to assistive technologies by default. For one, when non-interactive elements like spans of text and images are made dynamic, assistive technologies will not be aware that the user can activate them. As well, as actions occur, the changes to the content are not reflected in the accssibility tree (i.e., the new content will not be available).
These scripting accessibility problems plagued early development on the web, but the introduction of ARIA roles, states and properties has helped mitigate many of the problems. Adding these attributes to custom controls makes assistive technologies of their presence and allows information about the current state of the control to flow through to users.
The following list describes the purpose of each of these types of attributes.
- Roles
-
The ARIA
role
attribute is used to describe the function of a custom control (e.g., to indicate that an image functions like a button).Custom controls require a role in order to inform assistive technologies about their purpose. This allows the assistive technology to present the element to users according to its expected use.
Refer to the ARIA specification for the current list of supported roles.
- States
-
State attributes identify the current status of a control: whether it is currently checked or not, whether it is hidden, etc.
State attributes must be maintained by script as the user interacts with the control/content, otherwise the user may get locked out of functionality (e.g., unable to reduce the volume, unable to make important content visible, etc.).
Refer to the ARIA specification for the current list of supported states.
- Properties
-
Property attributes identify meta information about a control, such as the minimum or maximum value it allows or its place within a group.
Unlike states, properties are typically only set once when the content loads.
Refer to the ARIA specification for the current list of supported properties.
There is more to making custom controls accessible than just assuring that the correct roles, states and properties are applied, of course. Authors also need to make sure that they do not trigger unexpected changes in context, for example, when focus or input is received by the control.