Element Code: AC-033
What counts as a nested interactive control
Any focusable, activatable element sitting inside another one: a <button> inside an <a>, an <a> inside a <button>, an anchor inside an anchor, a link inside a <summary>, form controls inside a clickable label that maps to a different control, or anything with tabindex="0" or an interactive ARIA role (button, link, checkbox, tab) placed inside an element that already has one. Axe flags all of these under its nested-interactive rule and rates the issue serious, and this check mirrors that logic.
The HTML spec is blunt about it: the content model for <a> and <button> forbids interactive content inside them. This is not a style preference, it is invalid markup with runtime consequences.
Why it breaks things
One tab stop, two actions. Keyboard users get a single focus stop where two behaviors live. Which one fires on Enter? Depends on the browser and the event wiring. Some inner controls become unreachable by keyboard entirely, which fails WCAG 2.1.1 (Keyboard).
Screen readers pick one name. Assistive technology has to compute a single role and name for the focused thing. A "Read more" link wrapping a card that also contains a "Save" button often gets announced as one link whose name is the entire card text, with the button never announced at all.
The parser rewrites nested anchors. This is the part with direct SEO teeth. Browsers cannot represent an <a> inside an <a>, so the HTML parser closes the first anchor the moment it meets the second. Your DOM ends up with two sibling links whose boundaries and anchor text are not what your template says. Googlebot renders pages with the same parsing rules, so link extraction and anchor text run against the mangled version. I have watched an "entire card is a link" template quietly turn its card titles into empty anchors this way, and nobody had looked at the rendered DOM in a year.
Where I keep finding it
The same handful of patterns account for nearly every instance in real audits.
| Pattern | What breaks | Fix |
|---|---|---|
Whole card wrapped in <a> with a button inside | Button unreachable or unannounced; giant anchor text | Stretched link on the title, button as a sibling |
<a> inside <a> (card link plus inner tag links) | Parser auto-closes the outer anchor and splits the DOM | Restructure; nested anchors cannot exist as written |
<button> wrapping a link, or vice versa | Invalid HTML, double activation, focus confusion | Pick one control per action, move the other out |
Clickable <tr> via onclick, plus real links in cells | Row swallows clicks; AT sees a plain row, not a control | One real link in the row; extend its hit area with CSS |
tabindex="0" on children of a control | Two tab stops for one action, phantom focus targets | Remove inner tabindex; one focusable element per control |
How to detect it
- axe DevTools: the
nested-interactiverule names each offending node with a CSS selector. Run it on your card grid, your navigation, and one article template and you will have covered most of the site's components. - Lighthouse: the accessibility category runs a subset of axe, so nested controls surface in plain Chrome DevTools with no extension.
- Keyboard test: tab through a card component. If you can see a button you can never land on, or one tab stop visibly covers two actions, you have found it without any tooling.
- Source vs rendered DOM: for the nested anchor case specifically, compare view-source with the Elements panel. If anchors sit differently in the two, the parser has been rewriting your markup on every page load.
- Screaming Frog: a Custom Extraction with an XPath like
//a//a | //a//button | //button//ainventories the problem across the whole site in one crawl.
How to fix it, the pattern that works
For cards, the stretched link pattern solves this cleanly and it is what I put in every design system review. The card container is a positioned <div>. The title holds the only anchor. A pseudo element on that anchor (position:absolute; inset:0) stretches its clickable area across the whole card. Secondary actions like Save or Add to cart are sibling buttons layered above the overlay with position:relative and a higher z-index.
- Inventory instances with axe plus the Screaming Frog extraction above.
- For each, name the primary action. That element keeps the anchor or button; everything else becomes a sibling.
- Apply the stretched link pattern where a large hit area is wanted. Do not re-wrap the container in an anchor.
- Strip stray
tabindexattributes and interactive ARIA roles from children of controls. - Re-run axe, then re-do the keyboard pass: every visible control gets its own tab stop, in a sensible order, and Enter or Space activates exactly the thing that is focused.
What good looks like: valid markup where every interactive element is a leaf, anchor text that matches the visible link label, and a rendered DOM identical in structure to your source. Boring, predictable, crawlable.
DO
- Keep one interactive control per action, as siblings
- Use the stretched link pattern for large card hit areas
- Give the anchor the card title as its text, not the whole card
- Tab through components by hand after every refactor
- Compare source and rendered DOM when anchors behave oddly
DON'T
- Wrap entire cards in an anchor that contains buttons or links
- Nest an anchor inside an anchor, ever: the parser will not let it survive
- Add onclick to rows or containers that hold real links
- Sprinkle
tabindex="0"inside existing controls - Assume passing axe on one page clears a component used on two hundred
FAQ
Is this an SEO issue or just an accessibility issue?
Why does axe rate nested-interactive as serious rather than minor?
What is the right markup for a clickable card with a Save button?
Does a link inside a summary element count?
<summary> element is itself an interactive control (it toggles the disclosure), so a link inside it is a nested interactive and axe flags it. Put links in the expanded content of the details element instead, and keep the summary as a plain toggle label.One flagged component usually means a system-wide pattern
Nested controls ship from design systems, so a single axe finding often multiplies across every listing page you have. An Advanced SEO Audit traces flagged components to their templates and hands your developers exact, prioritized fixes.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
