Open Bug 1069739 Opened 8 years ago Updated 1 year ago

DIVs with overflow receiving focus, causing issues for accessibility user

Categories

(Core :: DOM: Selection, defect)

31 Branch
defect
Not set
normal

Tracking

()

UNCONFIRMED

People

(Reporter: kaushik.patel, Unassigned)

References

Details

Attachments

(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:
<html>
<body>
<input>
<div style="overflow-y:hidden"></div>
<input>
</body>
</html>

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
Kaushik,

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 https://developer.mozilla.org/en/Bug_writing_guidelines 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!
Status: UNCONFIRMED → RESOLVED
Closed: 8 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?
Status: RESOLVED → REOPENED
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.
Status: REOPENED → UNCONFIRMED
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: https://jsbin.com/biyapa/1/edit
Chrome 42 and IE11 do not show this behavior.

Note that https://bugzilla.mozilla.org/show_bug.cgi?id=626919 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)
Hello,

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:

https://codepen.io/alexcanessa/pen/JNmdgN


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 https://jsfiddle.net/sjnpd04v/

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.

(In reply to M from comment #23)

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.

Indeed, and that is precisely why this behaviour was implemented (a long time ago).

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

That's true, and in principle, I guess it'd be nice if the scrollable area wasn't focusable in the presence of focusable descendants. In practice, while I'm not super familiar with that area of the code, I imagine trying to actually implement this (accounting for dynamic mutations, CSS hiding, etc.) would be fraught with nasty edge cases and a world of pain.

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.

Add a mousedown listener which calls event.preventDefault(). I realise this might not be feasible in some cases due to other side effects (e.g. it will stop drag events from firing), but I thought it worth noting as a potential solution.

To be clear, I understand the concern for screen reader users here and it obviously isn't ideal. However, it also wouldn't be ideal if a keyboard only (non-screen reader) user couldn't scroll. I'm not sure we can reasonably sacrifice one for the other.

Hi James, thanks for the comments! That certainly helps clarify things, and I agree that it is useful and Inclusive for a scrollable element with no focusable children to be tabbable in this way.

In my particular use cases (both the one ~4 years ago and the one from yesterday), a role=listbox element is becoming tabbable in a way that a focus trap is created, which is of course its own (arguably worse) a11y issue. But, knowing that the scrollable-tabbable behavior is useful to some folks, we can work around it with the tabindex=-1 approach by adding an onFocus handler that redirects focus to an item in the listbox.

With that option, the most critical issue I'd like if we could improve here: the mysterious and undocumented behavior that results in my coworkers pulling their hair out trying to figure out why an element without a tabindex is suddenly tabbable, and in only one browser! At the very least it would be great if this was documented somewhere on MDN. Scott O'Hara also mentioned in a discussion yesterday that this behavior was intentional, and added that Chrome had actually tried to ship something similar maybe ~1 year ago but ran into some obstacles. So, perhaps this should also be brought up in the context of a W3C discussion to evaluate whether it belongs in a standards proposal.

Another idea I had -- and I don't know how feasible this would be in terms of both the browser engine and the OS native UI primitives -- would be to focus the scrollbar itself, rather than making the scrollable element tabbable. That would allow e.g. a sighted keyboard-only user to scroll the overflowing element in a way that is handled by the engine/OS, rather than handled spookily inside the DOM. I can't say I've ever seen a pattern like this before (maybe in early DOS days?), but an option I wanted to throw out :)

Thanks again for the attention on this.

Another issue with the status quo (for sighted keyboard users) is that these scrollable elements when focused do not have any default browser focus indicator. This violates WCAG 2.1 2.4.7 Focus Visible.

I'm also curious what exactly the heuristic is that FF uses to determine whether to place a scrollable element in the tab order? If it's documented somewhere (maybe on MDN as Craig mentioned above), then it'd be easier developers to target these elements when writing code (i.e. to do things like override the default browser focus indicator for all scrollable elements that FF has decided to put in the tab order).

(In reply to zelliottm from comment #27)

Another issue with the status quo (for sighted keyboard users) is that these scrollable elements when focused do not have any default browser focus indicator. This violates WCAG 2.1 2.4.7 Focus Visible.

How not? When I tab the testcase above I do get a focus ring.

I'm also curious what exactly the heuristic is that FF uses to determine whether to place a scrollable element in the tab order? If it's documented somewhere (maybe on MDN as Craig mentioned above), then it'd be easier developers to target these elements when writing code (i.e. to do things like override the default browser focus indicator for all scrollable elements that FF has decided to put in the tab order).

It's not quite an heuristic. The code is here, and it basically ensures that there's some scroll range, and it's an HTML element. So basically all scrollable boxes that you'd find. The other special-cases there are not particularly interesting, but I can explain them if you want.

How not? When I tab the testcase above I do get a focus ring.

My bad - I didn't notice the dotted, 1px outline. I was looking for the thick, blue focus ring that is rendered on form controls (https://codepen.io/zelliottm/pen/KKabavq) (I'm used to Chrome's keyboard focus indicator). I'm not sure if it meets contrast requirements per https://www.w3.org/WAI/WCAG21/Understanding/focus-visible-enhanced, but it's better than nothing. :)

Thanks for the link to the code. I guess the problem that I'm encountering is that I want to globally apply a stronger focus indicator to these elements, but I'm unable to do so with a CSS selector as I can with other tabbable elements (i.e. form controls, buttons, arbitrary elements with [tabindex], etc).

They do match the :focus-visible pseudo-class, is that not enough?

In my case that overmatches, I'd like to write as specific of a selector as possible. I think my best approach is to try to copy FF's logic with JavaScript to identify these elements.

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