Interactive controls such as buttons, links, and form fields must not contain other interactive controls or focusable elements. Each interactive control must be exposed independently in the accessibility tree. Nesting interactive elements creates invalid HTML and leads to inconsistent, unreliable behaviour across browsers and assistive technologies.
WCAG Success Criterion 4.1.2 — Name, Role, Value
User interface components must have a programmatically determinable name and role, and their states and properties must be available to assistive technologies.
Nested interactive controls can prevent one or more controls from reliably exposing a name or role, which may fail this criterion.
What Counts as an Interactive Control? (Beginner Context)
An interactive control is an element intended to receive user input or activation.
This includes:
Native interactive HTML elements
<button><a href><input><select><textarea>
ARIA-based interactive elements
Elements given interactive roles such as:
- button
- link
- checkbox
- radio
- menuitem
- switch
Important distinction:
Focusability alone (for example, tabindex="0") does not automatically make an element a valid interactive control. However, placing focusable elements inside interactive controls can still create serious accessibility and usability problems.
HTML Content Model Restriction
This is not just an accessibility recommendation; it is also an HTML validity rule.
The HTML specification explicitly forbids interactive content inside interactive content:
- A
<button>element must not contain interactive descendants - An
<a>element must not contain other interactive elements - Interactive ARIA roles cannot override these restrictions
When this rule is violated:
- The markup becomes invalid HTML
- Browsers may attempt to “repair” the DOM differently
- Focus, activation, and accessibility behaviour become unpredictable
ARIA cannot fix or override invalid HTML content models.
Why Nesting Interactive Controls Is a Problem
When interactive controls are nested:
- The DOM contains invalid interactive structures
- Browsers may flatten, ignore, or remap inner controls
- Assistive technologies may expose incomplete or conflicting semantics
- Keyboard focus and activation behaviour may vary unpredictably
The issue is not that inner controls are always “hidden”, it’s that behaviour becomes inconsistent and unreliable across browser and assistive technology combinations.
What Users Experience
Visually, nested controls may appear to work.
For keyboard and assistive technology users:
- Focus may land on an element with no clear announcement
- The inner control’s name or role may not be exposed correctly
- Activating one control may trigger another unexpectedly
- Navigation becomes confusing and error-prone
This can result in so-called empty or misleading tab stops, where focus moves but meaningful context is missing.
Correct Markup Example
Correct: One interactive control, no nested controls
<button>Submit</button>The control is valid HTML, focusable, and correctly exposed to assistive technologies.
Incorrect Markup Examples
Button containing a link
<button>
Save
<a href="#">More options</a>
</button>Problems:
<button>is interactive<a>is also interactive- This violates the HTML content model
- Browser and AT behaviour become inconsistent
ARIA button containing a link
<div role="button">
Search
<a href="#">Settings</a>
</div>Problems:
- ARIA creates an interactive control
- The nested link conflicts with that role
- Inner semantics may not be exposed reliably
ARIA roles do not make nesting safe.
Common Real-World Anti-Pattern
<a href="/product/1" class="card">
<h2>Product name</h2>
<button>Add to cart</button>
</a>Why this fails:
- <a> is interactive
- <button> is interactive
- This is invalid HTML
- Focus and activation behaviour are undefined
- Screen readers may announce only one of the controls
Correct Structure
<a href="/product/1" class="card">
<h2>Product name</h2>
</a>
<button>Add to cart</button>Style them visually as a group, but keep them separate in the DOM.
Why This Can Fail WCAG
Nested interactive controls can result in:
- One or more controls lacking a programmatically determinable name or role
- Incorrect or missing role exposure in the accessibility tree
- Confusing or broken keyboard interaction
This may result in failures of:
- 4.1.2 Name, Role, Value
- 2.1.1 Keyboard
- 2.4.3 Focus Order
The exact impact depends on browser and assistive technology behaviour, which is precisely why nesting must be avoided.
How to Fix the Problem
- Do not nest interactive elements inside other interactive elements
- Separate actions into sibling controls
- Use CSS for layout and visual grouping
- Choose one control per action
If something looks like multiple actions, it must be multiple controls, not nested ones.
How This Is Tested
Accessibility tools and audits typically check whether:
- Interactive elements contain focusable descendants
- Buttons, links, and ARIA widgets wrap other controls
- Focus order exposes each control independently
Automated tools often flag these patterns, though detection depends on the rule implementation and markup used.
Manual testing with keyboard navigation and screen readers is strongly recommended.
Wrapping Up
Interactive controls must be atomic.
- One control
- One action
- One focus target
Nesting interactive controls creates invalid HTML, unpredictable browser behaviour, and broken accessibility experiences. If an element can receive user input, it must not contain another element that can also receive user input. Anything else introduces unnecessary risk and frequently results in broken or inconsistent experiences for keyboard and assistive technology users.
