interactable-role
Web validation
role attribute.Every interactive element, such as a <button>, <a>, or <input>, carries a built-in role that tells assistive technology what it does. A non-semantic element like a <div> or <span> has no such role.
When a <div> or <span> is wired up to act like a control but has no role, screen readers announce it as plain text and keyboard users may not reach it. People are left guessing about its purpose and behavior.
Pass Patterns
Semantic element used as intended
A native <button> exposes the button role, keyboard focus, and default activation keys.
<button class="btn-primary">Save</button>Non-semantic element given a role
A <div> gets a role, tabindex, and an accessible name, so assistive technology treats it as a button. Use this only when a native element cannot be used.
<div role="button" tabindex="0" aria-label="Save" onclick="handleSave(event)"></div>Fail Patterns
Clickable element with no role
The <div> looks and behaves like a button but has no role, so assistive technology treats it as plain text.
<div onclick="handleSave(event)" style="cursor: pointer">Save</div>WCAG techniques
Sufficient techniques
- ARIA4: Using a WAI-ARIA role to expose the role of a user interface component
- G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes
- H91: Using HTML form controls and links
Failure techniques
- F59: Failure of Success Criterion 4.1.2 due to using script to make div or span a user interface control in HTML without providing a role for the control
- F42: Failure of Success Criteria 1.3.1, 2.1.1, 2.1.3, or 4.1.2 when emulating links
Try It Yourself
Using a screen reader
New to screen reader testing, or need a refresher?
Review this article first: Practical guides for using screen readers
- Load the page and turn on a screen reader.
- Use quick-nav keys to move between controls, such as B for buttons in NVDA.
- Move to the control and listen.
Expected results: The screen reader announces a name and a role, such as "Save, button".
Actual results: The screen reader announces only "Save" or skips the element, because it has no interactive role.
Using a keyboard
- Press Tab to move focus toward the control.
- Press Enter or Space.
Expected results: Focus reaches the control and the action runs.
Actual results: Focus never reaches the element, or the keys do nothing.
FAQ
How does this issue relate to 4.1.2 Name, role, value?
SC 4.1.2 requires a component's role to be programmatically determinable. An interactive element with no interactive role cannot be identified or operated by assistive technology, so it fails the criterion.
Why is this issue marked as Critical?
Without a proper role, many users cannot perceive or operate the control, which can block core tasks like submitting a form or navigating. The barrier affects every major browser and assistive technology.
Standards and Regulations
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, 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 assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.21(d) | Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. |