nested-interactive
Web validation
When one focusable control (like a <button>, <a>, or custom element with role="button") contains another focusable control, assistive technologies only expose the outer control. The inner element may still receive keyboard focus, but screen readers don't announce its name or role, so users can't tell what it is or reliably operate it, and users who rely on precise pointer movement may activate the wrong control. Always keep interactive elements separate, or make the outer element non-interactive.
Pass Patterns
Controls do not nest within each other
Each of the controls stands on its own, even though they are semantically related.
<button type="button">Settings</button>
<ul>
<li><a href="/options">Advanced settings</a></li>
</ul>Fail Patterns
An anchor nested inside a button
A link inside a button: the button's children are presentational, so the link's role isn't exposed.
<button type="button">
Save
<a href="/more">More options</a>
</button>Native focusable element nested within a custom control
Focusable descendant inside an element that already has role="button".
<div role="button" tabindex="0">
Search
<input type="text" placeholder="Enter keywords" />
</div>WCAG techniques
Sufficient techniques
ACT Rules
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, open a screen reader.
- Move to the control with the nested interactive element.
- Listen to what the screen reader announces.
Expected result: The screen reader speaks both controls’ names and roles separately.
Actual result: The screen reader speaks both controls' names together and doesn't announce the inner element's role. If focus reaches the inner element, it's announced incompletely or not at all.
FAQ
How does this issue relate to 4.1.2 Name, role, value?
SC 4.1.2 requires every user-interface component to expose a name, role, and state through the accessibility tree. When an interactive element is nested inside another, the inner element’s role and name are suppressed, causing a failure of this criterion.
Why is this issue marked as Serious?
Losing access to nested controls blocks key tasks for keyboard and screen-reader users and can cause accidental activation for pointer users. Because it interferes with operation on critical input methods across all major browsers and assistive technologies, the impact is considered serious.
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. |
| 508 Trusted Tester | 2.4.4-link-purpose, 6.A | The purpose of each link or button can be determined from any combination of the link/button text, accessible name, accessible description, and/or programmatically determined link/button context. |