Open Bug 1069739 Opened 6 years ago Updated 3 months ago

DIVs with overflow receiving focus, causing issues for accessibility user


(Core :: DOM: Selection, defect)

31 Branch
Not set





(Reporter: kaushik.patel, Unassigned)




(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36

Steps to reproduce:

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9

An div element with overflow-y:hidden in its style is focusable

Reproducible: Always

Steps to Reproduce:
<div style="overflow-y:hidden"></div>

Actual Results:  
div is focusable

Expected Results:  
div should not receive focus up on tabbing

Actual results:

Accessibility user uses keyboard TAB key to navigate across the Web-Page.
In the above case, the DIV receives the focus and nothing can be announced by Screen Readers , creating confusing and usability issue for these users.
Ours is a Web Based Enterprise application and this issue is critical for us to receive 508 compliance for us

Expected results:

Div should not receive focus
Priority: -- → P1

This doesn't need to be security sensitive. Please don't change the priority. Leave that to the developers.

You filed this under version 32 but the actual useragent values were for a beta version of Firefox 4.
Group: core-security
Priority: P1 → --
Attached file testcase
Attachment #8492001 - Attachment mime type: text/plain → text/html
Marco, I can't reproduce this on Linux. Can you check it out?
I cannot reproduce this on Windows using Firefox 32 or 35 Nightly, with either NVDA or JAWS. Both inputs are focusable just fine and I can type in them. No problem as far as I can see.
Thanks Marco!

Kaushik, it is not clear to me what build you were actually testing. If it was really Firefox 4 beta, that is far too out of date. I'm going to mark this as works for me. Please read and if you can reproduce it with a current build, please reopen and give us detailed instructions on how to reproduce and exactly which build you were using. Thanks!
Closed: 6 years ago
Resolution: --- → WORKSFORME
Attached file FFDIV.html
The Div receives the Focus in FF ESR 31.0
I have attached the sample HTML where the DIV receives the focus.
Kaushik, that attachment was only example data and did not in any way contain real information on names and salaries?
Flags: needinfo?(kaushik.patel)
Attached file FFDIV.html
semi reduced FFDIV.html
I can reproduce the focus issue with Nightly 35 on Linux.

Marco, which product/component should we put this?
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86_64 → All
Resolution: WORKSFORME → ---
Version: 32 Branch → 31 Branch
Ya..the data in the table is just an example data
Flags: needinfo?(kaushik.patel)
I still don't see the problem, or I didn't understand it. To me this looks like a contentEditable table that I can navigate with my Windows screen reader. Note that contentEditable for tables is not well defined and in general behaves badly. This is an Editor bug, IMO.
Marco, when I tab in Firefox the focus changes from the urlbar to the search input to the document and then to the table. In Chrome 37 the urlbar is focused and blurred only. I'll move this to Core Editor for triage.
Component: Untriaged → Editor
Ever confirmed: false
Product: Firefox → Core
Confirming that <div style="overflow:auto"> is focusable in Firefox 37 Mac. Focus can be set by script and keyboard, however not by mouse. A simple test case can be found here:
Chrome 42 and IE11 do not show this behavior.

Note that looks like a duplicate (or this one is, since the other issue is older).
To be clear, despite the example in the first post, this bug occurs whenever a scrollbar is present. This can be with overflow-x or simply overflow: auto.

For anyone experiencing this bug, setting a normally unnecessary tabindex="-1" can disable the focusing.
This issue is still not fixed in v.45.2.0. Are there any plan to get this issue fixed in the upcoming versions?
- It's not a fare idea to keep adding tabindex='-1' to every element (having overflow:auto) only for firefox browser.
(In reply to satheeshdom from comment #17)
> This issue is still not fixed in v.45.2.0. Are there any plan to get this
> issue fixed in the upcoming versions?
> - It's not a fare idea to keep adding tabindex='-1' to every element (having
> overflow:auto) only for firefox browser.

I agree with satheeshdom, is this going to be fixed any time soon? Pretty big issue and it's only in Firefox.
+1. The "tabindex=-1" has the rather unpleasant side effect of making nodes click-focusable.
Flags: needinfo?(m_kato)
per comment #15's sample, this doesn't use contenteditable.  Is this Core: Selection or DOM: ?
Component: Editor → Selection
Flags: needinfo?(m_kato)
Flags: needinfo?(bugs)

This is what I've found out:

When a div contains an element that is bigger (either taller or wider) than the parent and has the property overflow-x or overflow-y set to any value, then it can receive the focus.

See an example below:

Testing on:

MacBook Pro (Retina, 15-inch, Late 2013)
Firefox 53.0.2
OS 10.12.3 (Sierra)
Clearly ni on Jet as he no longer works at Mozilla.
Flags: needinfo?(bugs)
See Also: → 1532965

A more accurate title is "DIVs with [scrollable] overflow receiving focus, causing issues for accessibility user".

Here is a minimal reproduction of the behavior

This behavior may be beneficial, when the scrollable element contains no focusable children. If the scrollable element would not be able to receive focus, then a keyboard-only user would not be able to focus and scroll the element. This is in fact the case in Chrome, where in the test case above you can not focus the .focusable div.

When the scrollable element does have focusable children, tabbing through the container becomes unnecessary.

As Craig points out, adding tabindex="-1" makes the element click focusable on both Firefox and Chrome.

The issue is that it is considerably more difficult to stop this behavior than it is to enable it, which can be done with tabindex="0" on elements you want to receive focus.

I'm not aware of any way to stop this behavior without JavaScript and even then I don't know how it should be done.

You need to log in before you can comment on or make changes to this bug.