Nested Interactive Controls: Why a Button Inside a Link Breaks Accessibility
A nested interactive control is one focusable element placed inside another - a button inside a link, a link inside a button, or the most common version, a clickable card where the whole thing is a link and there is a button inside it too. HTML does not allow this, and assistive technology cannot make sense of it: the inner control is not announced to screen readers, and keyboard users land on an empty tab stop where focus goes but nothing is read. We found nested interactive controls on 15 of the 299 large US home pages we scanned. It fails WCAG Success Criterion 4.1.2 (Level A). The fix is structural - make the controls siblings instead of nesting them.
This one usually comes from a good intention: make the whole card clickable. A team wraps an entire product or article card in an <a>, then drops an "Add to cart" or "Read more" button inside it for good measure. It looks fine and clicks fine with a mouse. But now there is a button inside a link, and for a screen reader or keyboard user the component is broken. This page covers what counts as nesting, who it breaks things for, and how to build the clickable-card pattern correctly.
What "nested interactive" means
Interactive elements - links, buttons, form fields, selects - are meant to be the leaves of the tree, not branches that contain other controls. The HTML specification disallows interactive content inside an <a> or <button>, and the axe rule that flags it maps to WCAG Success Criterion 4.1.2 Name, Role, Value, at Level A: when controls are nested, the inner one's role and state cannot be communicated reliably.
<!-- Broken: a button nested inside a link -->
<a href="/product">
<h3>Trail Runner</h3>
<button>Add to cart</button>
</a>
<!-- Fixed: the link and button are siblings -->
<div class="card">
<h3><a href="/product">Trail Runner</a></h3>
<button>Add to cart</button>
</div>
Who this shuts out
- Screen reader users, who do not hear the nested control announced at all - as the axe documentation puts it, "focusable elements with an interactive control ancestor are not announced by screen readers and create an empty tab stop."
- Keyboard-only and mobility-impaired users, who tab to the inner control, land on it, and get nothing - a focus stop that does not work and cannot be operated.
How common is it?
In our State of Web Accessibility 2026 study of 299 large US home pages, 15 (5%) had nested interactive controls. It tracks with modern component design: card grids, product tiles, and article previews that try to be both a big clickable link and a container for buttons and secondary links. The more a home page leans on clickable cards, the more likely this turns up.
The usual culprits
- The clickable card - the whole card wrapped in an
<a>, with a button or a second link inside it. - A link inside a button, or a button inside a link, in a toolbar or menu.
- Nested links - an
<a>containing another<a>. - A control inside a clickable table row that is itself made interactive.
How to fix it
- Find the nested controls with a scan or axe DevTools.
- Make them siblings. Put the link and the button next to each other, not one inside the other.
- Rebuild clickable cards with a single link - make the heading a real link and keep other controls as siblings, rather than wrapping the whole card in an
<a>. - Use a stretched link if you want the whole card clickable: a CSS pattern where the heading link's clickable area is expanded with an absolutely-positioned pseudo-element, with no other controls nested inside it.
- Re-test by tabbing - confirm there are no empty stops, then re-scan.
What a scan can and cannot tell you
This is reliably caught: nesting is a fact about the markup structure, so a scanner finds every case and points at it. There is little judgment left here - the fix is structural, and the only real decision is how to rebuild a clickable card, which the stretched-link pattern solves. We report the automated slice; a full audit confirms the rebuilt component works with a keyboard and a screen reader.
Common questions
What does "nested interactive" mean? One interactive control inside another - a button in a link, or a clickable card with a button inside.
Can I put a button inside a link? No - it is invalid HTML and the button is silent to screen readers. Make them siblings.
How do I make a clickable card accessible? One real link (usually the heading), other controls as siblings, and a CSS stretched link if you want the whole card clickable.
Does it fail WCAG? Yes - 4.1.2 (Level A).
Check your own site
Run a free check on your home page to find any nested interactive controls, with the element to fix, in about a minute. For the whole site, a full audit confirms the rebuilt components work by keyboard and screen reader, and monitoring catches the pattern when a new card component ships. For the data behind this page, read the State of Web Accessibility 2026; its closest companions are links and buttons without accessible names.