A: Custom controls have appropriate ARIA roles (WCAG 4.1.2)
custom-controls-roles
This means
Custom interactive elements such as buttons, sliders, or drop-down menus require a semantic role that describes their function in the interface. This role is defined using the role attribute and helps assistive technologies recognize how an element should be operated.
Impact
If the correct ARIA role is missing, screen readers will not recognize controls as interactive. Users do not know that they can operate the element. This leads to a loss of functionality and violates WCAG 4.1.2 (A) “Name, Role, Value”.
Recommendation
- Always assign a suitable ARIA role to custom elements (e.g.,
role=“button”,role=‘slider’,role=“checkbox”). - The role must reflect the actual function.
- If possible, prefer native HTML elements, as these automatically have a role.
- Make sure that each role is compatible with the intended keyboard controls (e.g., space bar for buttons, arrow keys for sliders).
Examples
Problematic: A clickable <div> without a role or keyboard focus is ignored by screen readers.
<div onclick="submitForm()">Submit</div>
Better: The same element with role=“button” and correct focus behavior is recognized and can be operated.
<div role="button" tabindex="0" onclick="submitForm()">Submit</div>
Note
This test criterion does not evaluate the design, but rather the semantic accessibility. The correct ARIA role is crucial for assistive technologies to interpret the behavior correctly.
Related WCAG criterion:
WCAG 4.1.2 – Name, Role, Value