How Nested Interactive Controls Break Ecommerce Accessibility

Ever run an audit and get flagged for “nested interactive controls issues”? Yeah, that vague but very real accessibility issue that breaks buttons and links, especially on e-commerce sites, causes a ton of headaches for screen readers and keyboard users.

I run into this all the time when I’m doing accessibility checks on product pages. And honestly, it’s sneaky because at first glance, the code looks fine. The UI even works for mouse users. But under the hood? It’s a mess.

So, what does this error actually mean?

If you’re running into nested interactive controls accessibility issues and you’re not sure what’s causing them, you’re not alone. In short, you’re putting a clickable thing inside another clickable thing. Sounds harmless. But it’s a major accessibility fail.

Assistive tech like screen readers and keyboard navigation gets confused when one interactive thing lives inside another… and confused assistive tech = frustrated users.

Screen readers and keyboard nav rely on clear roles and focus paths. When you nest interactive stuff, that structure falls apart. So what happens?

• Users might not be able to reach the inner button at all

• They might hear the wrong label, or nothing at all

• Focus might get stuck or jump weirdly

Why it’s everywhere in ecommerce

Nested interactive controls are everywhere on ecommerce templates, designers and devs love to make whole product cards clickable. You hover over a product, and the entire box acts like a giant link. But inside that box? There’s usually an “Add to Cart” button. Boom. That’s two actions inside one control.

And because a lot of these are built on Shopify themes or copied patterns, this mistake spreads like glitter at a craft table.

Worse is that this simple issue is breaking 3+ WCAG criteria at once.

The rules this breaks

• 1.3.1 Info and Relationships – the roles and structure get all scrambled
• 2.1.1 Keyboard – not everything is reachable with a keyboard
• 4.1.2 Name, Role, Value – assistive tech can’t figure out what each thing is
• And for good measure: ARIA 1.1 says no nesting interactive children inside interactive parents (source)

A quick example:

<a href="/product-page" class="card-link">
  <div class="product-card">    
    <h2>Product Name</h2>
    <p>$19.99</p>
    <button>Add to Cart</button> <!-- ❌ Don’t do this -->
  </div>
</a>

Looks simple. Looks clean. But this is a trap.

• <a> is already interactive
• <button> is also interactive
• One inside the other = no bueno

You now have two different roles fighting for attention, and only one can win. Spoiler: screen reader users lose.

Fix it like this:

If the two controls do different things (e.g. “View Product” and “Add to Cart”), keep them separate. Side by side. Not nested.

<div class="product-card">
  <a href="/product-page" class="card-link">
    <div class="card-content">
      <h2>Product Name</h2>
      <p>$19.99</p>
    </div>
  </a>
  <button class="add-to-cart">Add to Cart</button>
</div>

Now the link and button are separate.

Keyboard users can tab to both.

Screen readers can announce each one clearly.

Then use CSS to style them however you want. Float the link over the card, position the button… go wild. Just don’t mix the HTML roles.

Recap:

• This shows up a lot in Shopify themes, and it’s not always easy to spot
• Don’t wrap links or buttons around other interactive elements
• Use real semantic elements, no fake buttons
• CSS can make things look clickable, but HTML has to make them usable
• Test your code. If it feels weird with a keyboard, it’ll feel impossible with a screen reader.
• You can check my codepen

Fix it once, and you’ll stop failing 3+ WCAG checks in one shot, welcome!!