Incorrect/incomplete use of ARIA for the custom control fails to expose an element to assistive technologies.
Description
Incorrect/incomplete use of ARIA for the custom control fails to expose an element to assistive technologies.
Rule
The name, role, value, states, and properties of user interface components MUST be programmatically determinable by assistive technologies.
Background
Every user interface control must have a role along with any applicable states and properties so that screen reader users know how to interact with the control. Native HTML elements — such as <button>, <a>, <input>, <select> — already have a role, and their necessary states and properties — such as the checked/unchecked state of a checkbox — are automatically conveyed so nothing more needs to be done. For this reason, it is always preferred to use native HTML elements when possible.
If you do create a custom version of a native HTML element or a custom control or widget that does not have a native HTML equivalent, you must add the relevant role(s) and any applicable states and properties using ARIA as well as expected keyboard interactions.
Code Examples
Good Examples:
List used as tablist has ARIA role:
<ul role="tablist">
<li role="tab">Home</li>
<li role="tab">Products</li>
<li role="tab">Services</li>
</ul>How To Fix
To fix this issue:
- Make sure you use all of the necessary ARIA. See the WAI-ARIA Authoring Practices document for a description of the roles, states, properties, and keyboard functions your custom control should contain.
- Use the appropriate aria roles, states, and properties for your custom control.
- Apply expected keyboard functions to your custom control
Don't do this:
- Invent a new aria role. There is a long list of ARIA roles, but it is a finite list.
- Assume that all users will interact with your control using a mouse.