Interactive controls must not be nested

HTML has a clear content model: interactive elements like <button>, <a>, <select>, and <input> are not allowed to contain other interactive or focusable elements. When you nest one interactive control inside another — for example, placing a link inside a button — browsers and assistive technologies handle the situation inconsistently and unpredictably.

Screen readers are especially affected. When a user tabs to a nested interactive element, the screen reader may produce an empty or silent tab stop. The inner control’s name, role, and state are not announced, meaning the user has no idea what the control does or that it even exists. This creates a serious barrier for blind users who rely on screen readers and keyboard-only users who navigate by tabbing through focusable elements.

This issue also affects users with mobility impairments who use switch devices or other assistive input methods that depend on an accurate understanding of the interactive elements on the page.

Related WCAG Success Criteria

This rule maps to WCAG 2.0, 2.1, and 2.2 Success Criterion 4.1.2: Name, Role, Value (Level A). This criterion requires that for all user interface components, the name and role can be programmatically determined, and states, properties, and values that can be set by the user can be programmatically set. Nested interactive controls violate this because the inner control’s name and role become inaccessible to assistive technology.

How to Fix It

The fix is straightforward: do not place focusable or interactive elements inside other interactive elements. Here are common strategies:

1. Separate the controls. Place interactive elements side by side rather than nesting them.
2. Restructure the layout. If a design requires a clickable card with inner links or buttons, use CSS positioning or JavaScript event delegation rather than literal nesting.
3. Check elements with ARIA roles. A <div> with role="button" is treated as an interactive control. It must not contain links, buttons, inputs, or any other focusable elements.

Examples

Incorrect: Link Nested Inside a Button

The <a> element inside the <button> creates a nested interactive control that screen readers will not announce properly.

<button>
  Save
  <a href="/options">More options</a>
</button>

Incorrect: Link Nested Inside an Element with role="button"

Even though the outer element is a <div>, the role="button" makes it an interactive control. The nested <a> is inaccessible to screen readers.

<div role="button" tabindex="0">
  Search
  <a href="/settings">Settings</a>
</div>

Incorrect: Button Nested Inside a Link

Placing a <button> inside an <a> element is equally problematic.

<a href="/dashboard">
  Go to dashboard
  <button>Settings</button>
</a>

Correct: Separate Interactive Controls

Place each interactive element independently so both are fully announced and operable.

<button>Save</button>
<a href="/options">More options</a>

Correct: Clickable Card with Separate Controls

If you need a card-like pattern where the entire card is clickable but also contains separate actions, avoid literal nesting. Use a flat structure with CSS for layout.

<div class="card">
  <h3><a href="/article/1">Article Title</a></h3>
  <p>A short description of the article.</p>
  <button>Bookmark</button>
</div>

Correct: Single Button with No Nested Interactive Content

A simple, properly structured button with only non-interactive content inside it.

<button>
  <svg aria-hidden="true" focusable="false">
    <use href="#icon-save"></use>
  </svg>
  Save
</button>

Note that in the example above, the <svg> element has focusable="false" to prevent it from being a tab stop in some browsers (notably older versions of Internet Explorer and Edge), and aria-hidden="true" because the button text already provides the accessible name.

Learn more:

Deque Reference

Deque University - How To Fix

→