Open Bug 1106045 Opened 10 years ago Updated 2 years ago

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

Categories

(Firefox :: Disability Access, defect)

33 Branch
x86_64
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: eternal.linux, Unassigned)

References

()

Details

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="#">
        <div>
            The link text
            <button type="button">Button 1</button>
            <button type="button">Button 2</button>
        </div>
    </a>

(I have created a JSFiddle illustrating the problem at http://jsfiddle.net/jjxuL1tz/5/ .)

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.

Workaround
==========

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 (http://jsfiddle.net/jjxuL1tz/5/).
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.

[1] http://www.w3.org/TR/html5/forms.html#the-button-element
[2] http://www.w3.org/TR/html5/text-level-semantics.html#the-a-element
So is this an invalid bug, then, and should we close it accordingly?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.