Introduction
I often run into this accessibility issue where developers place nested focusable elements within each other. For example, a button was placed within a link like this:
<a href="#">
<button>Go to the homepage</button>
</a>
The 5 issues with nesting focusable items
There are lots of accessibility issues that come with nesting focusable items.
Issue 1 – One role allowed
An element MUST only have one role. Something can’t be two different things at a time. Each role (control type) is meant to perform a specific action. Users know links will take a user to a different location, whereas a button will trigger some action. It may be confusing to determine what action will occur when they’re both announced as “button, link.”
Issue 2 – Compatibility issues
Screen readers will often run into complications when announcing these items. Some screen readers might announce the code snippet above as a “link,” and others might announce it as a “button,” or in some cases, “button link.”
Issue 3 – Categorization problems…Is it a button or a link?
Screen readers might place this item in the wrong category. Jaws has a function to list links and list buttons. This poses the question, where should JAWS the screen reader categorize it.
Issue 4 – Invalid HTML markup
This is invalid HTML. It fails when running through the NU validator. Thus failing WCAG 4.1.1 Parsing.
Issue 5 – Focus problems
These elements will receive focus twice which is unnecessary for keyboard-only users.
Recommendation
For starters, don’t nest multiple focusable elements together. Also before choosing both, really stop and think which is the needed control type that is most relevant to your needs. If you need a collection of patterns to choose from, you could reference them from the WCAG 1.2 Design Specs.
In short, if you need something that looks like a button, simply use the anchor link tag and CSS to style it. Use the button element without the anchor link if you need a pure button.
Don’t nest multiple focusable elements…
