A card component wraps its entire markup in an <a href> and that markup contains a <button>. Why does HTML's content model forbid this, and what would you do instead?

## The rule The HTML specification defines a category called **interactive content**: elements users can interact with directly. Its members are `a` (when it has an `href`), `button`, `details`, `embed`, `iframe`, `label`, `select`, `textarea`, `input` (unless `type="hidden"`), and `audio`/`video` when the `controls` attribute is present. The `a` element's content model is transparent — it accepts what its parent accepts — **but with no interactive content descendant, no `a` element descendant, and no descendant with the `tabindex` attribute specified.** So a card entirely wrapped in an anchor may legally contain headings, paragraphs, images and spans, and may not contain a button, an input, a select, an iframe or another link, however deeply nested. The same prohibition runs the other way for `button`, whose content model is phrasing content **with no interactive content descendant** — so a link inside a button is equally invalid. ## Why the spec bothers Nesting two activatable elements creates a region with two competing activation behaviours and no principled way to resolve them: - **Pointer.** A click lands on the button, but the event continues up through the anchor, which also has activation behaviour. What the user gets depends on what the button's own handling does, which is exactly the kind of thing that differs between implementations and breaks on refactor. - **Keyboard.** Both elements are focusable, so tabbing puts the user inside a link, then inside a button that lives inside that link, with no announced boundary explaining the relationship. - **Accessible name.** A link's name is computed from its contents. The button's label is text inside the anchor, so it gets swept into the link's name — the link ends up announced as "Release notes Everything that changed this month Save for later", which is useless in a list of links. - **Assistive-technology navigation.** Users who list all links or all buttons on a page get entries whose boundaries do not match anything visible. The parser also does not clean this up for you the way it does for nested anchors. `<a><a>` is repaired — a second `a` start tag closes the first — so nested links end up as siblings. A `button` inside an `a` is simply left as authored: the DOM keeps the invalid structure, and the runtime confusion is real rather than theoretical. ## What not to do The reflex fixes all make it worse: - Swapping the inner `<button>` for a `<div>` with a click handler removes the validity error and the keyboard access at the same time. The control is now unreachable for anyone not using a mouse. - Adding `tabindex` anywhere inside the anchor is explicitly called out by the anchor's content model as forbidden. - Swapping the outer anchor for a `<div>` with a click handler destroys the link: no middle-click, no open-in-new-tab, no copy-link, no crawlable destination, and the region disappears from the page's list of links. Every one of these trades a validation error for a real user-facing regression. ## The restructure The honest fix is to stop overlapping the regions. ```html <div class="card"> <a href="/posts/1"> <h2>Release notes</h2> <p>Everything that changed this month.</p> </a> <button type="button">Save for later</button> </div> ``` The anchor wraps only non-interactive content — legal, because the anchor's transparent content model inherits the container's permission to hold flow content. The button is a sibling inside the card container. Now there are exactly two activation targets, each with its own boundary, its own accessible name and its own tab stop. When the design insists the entire card surface be clickable, the markup pattern is the same shape: one anchor, on the card's title, with the card container around it and the secondary controls as siblings. The card-wide hit area is then a presentation concern layered on top of markup that is already correct, rather than something the markup has to fake by swallowing the controls. ## What an interviewer is checking That you recognise it as a content-model violation with a named rule, not a lint nit; that you can say why two nested activation targets are undecidable rather than just "it's bad practice"; and that your fix restructures the markup instead of trading a real element for a div plus attributes. Reaching for `tabindex` or a click-handling div here is the answer that fails the question.