Rule library Keyboard and focus

Interactive controls must not be nested

nested-interactiveWCAG 2.0 A

Ensure interactive controls are not nested as they are not always announced by screen readers or can cause focus problems for assistive technologies

Who this affects

Interactive controls are nested inside one another — for example a button inside a link. Screen readers announce these unpredictably and keyboard focus order breaks.

How to fix it

Flatten the structure so each control stands on its own.

Effort Medium · ~30 min

Before and after

Fails

<button>
  <a href="/terms">Terms</a>
</button>

Passes

<button>Accept</button>
<a href="/terms">Terms</a>

Where this sits in the standard

WCAG success criterionLevelEN 301 549 clause
4.1.2 Name, Role, ValueA301-549, 9.4.1.2

EN 301 549 clause 9 applies these criteria to web content. The published version referenced by the European Accessibility Act is V3.2.1, which incorporates WCAG 2.1 level A and AA. More on the standard.

How to check it by hand

Put the mouse down. Tab from the top of the page to the bottom. Every interactive element must be reachable, must show a visible focus indicator, and you must be able to tab back out of anything you tab into.

Automated testing settles roughly a third of the WCAG success criteria. This rule is one an automated tool detects reliably — but a clean automated result is not proof of conformance.

Reference

Deque's technical write-up for this rule: nested-interactive

See whether your site trips this rule

Paste a URL. We open it in a real browser, dismiss the cookie wall and run the full EN 301 549 rule set. No account, no card.

Run a free scan All rules