The use of ARIA roles, states and properties is necessary to ensure that custom controls are accessible to users of assistive technologies.
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]
Although HTML provides a number of native controls (e.g.,
progress), developers often have to create their own equivalents to avoid the styling
limitations or introduce specialized functionality.
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.
roleattribute 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.
The supported roles for custom controls are as follows:
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.).
The state attributes include the following:
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.
The property attributes include the following: