Error Interactive content nested inside a link or button
Why a <button> or form field can't live inside an <a>, and the click-handling and accessibility bugs that nesting causes.
The validator flags an <a> or <button> that contains another link, button, or form field (input, select, textarea, and similar) as a descendant.
Example
<!-- Wrong: button inside a link -->
<a href="/product/42">
View product
<button>Add to cart</button>
</a>
<!-- Right: siblings, styled to look related -->
<div class="product-row">
<a href="/product/42">View product</a>
<button>Add to cart</button>
</div>Why it matters
The HTML spec categorizes links, buttons, and form controls as "interactive content," and its content model rule is that interactive content cannot contain other interactive content. Browsers don't uniformly reject this at parse time the way they do with same-tag nesting (an <a> inside an <a> gets auto-closed by the parser), so a <button> inside an <a> often does render — but click handling becomes ambiguous, keyboard and screen-reader navigation gets confusing (which control receives focus? which one activates on Enter?), and browsers vary in exactly how they resolve the conflict. This is a frequent bug in card-style UI where a whole card is wrapped in a link and then a secondary action button is added inside it.
Frequently asked questions
Why does the page still look fine if this is invalid?
Most browsers will render nested interactive elements visually without complaint, so it's easy to miss. The real problems show up in behavior: inconsistent click targets, screen readers announcing a confusing nested control, and keyboard focus order that doesn't match what a user expects.
What's the right pattern for a clickable card with a secondary button?
Keep the link and the button as siblings rather than nesting one inside the other, and use CSS (an absolutely positioned link covering the card, or a flex/grid layout) to achieve the "whole card is clickable" visual effect without violating the content model.