Open Bug 1106045 Opened 5 years ago Updated 2 months ago

<input>s within <div>s within <a>s create focus cycles


(Firefox :: Disability Access, defect)

33 Branch
Not set





(Reporter: eternal.linux, Unassigned)




What did you do?

I was testing a Web application for keyboard accessibility. In the application there were some HTML structures like the following:

    <a href="#">
            The link text
            <button type="button">Button 1</button>
            <button type="button">Button 2</button>

(I have created a JSFiddle illustrating the problem at .)

I attempted to tab through this structure to focus elements further on in the HTML.

What happened?

I became stuck in a focus cycle. That is, pressing Tab when Button 2 was focussed returned focus to the parent <a> tag, so the focus went as follows:

    <a> -> Button 1 -> Button 2 -> <a> -> Button 1 -> ...

When <a> was focussed, I could press Shift+Tab to get out of the cycle and focus the previous element in the document, but I could not focus the element after the cycle without using the mouse.

What should have happened?

With Button 2 focussed, I should have been able to press Tab to focus the next element on the page.


The problem does not occur if the <button>s are replaced with <a>s; indeed, adding one <a> tag as a sibling of the <button>s fixes the problem, even if it has its `tabindex` attribute set to -1.

An example of this can be found in the JSFiddle (
I should also mention that the issue still occurs on a clean Firefox profile.
I can confirm the behavior on Mac OS X 10.8.5 with Firefox Nightly 37.0a1 (2015-01-04).

Note that both, <button> [1] and <a> [2] elements are not allowed to contain any form of interactive content. Both elements fall into that category making your example invalid HTML. The described workaround would nest two <a> elements, thus also being invalid HTML.

So is this an invalid bug, then, and should we close it accordingly?
You need to log in before you can comment on or make changes to this bug.