New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 271023 link

Starred by 16 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment

Outline should not appear on elements focused by mouse

Reported by oliverj...@gmail.com, Aug 9 2013

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1591.0 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Disable the "Pressing Tab on a web page highlights links, as well as form fields" option
2. Use the keyboard to tab through items on a web page / mouse down on a button (but do not mouse up)

What is the expected behavior?
There should be no outline on the focused element.

What went wrong?
There is an outline, with or without the setting enabled. It also appears when you click on an element too, whereas before I believe it only appeared when you used the keyboard to tab onto the element.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes 

Does this work in other browsers? Yes 

Chrome version: 30.0.1591.0  Channel: canary
OS Version: OS X 10.9.0
Flash Version: Shockwave Flash 11.8 r800
 
Screen Shot 2013-08-09 at 22.42.56.png
13.4 KB View Download

Comment 1 by meh...@chromium.org, Aug 10 2013

Labels: Cr-Blink

Comment 2 by tkent@chromium.org, Aug 11 2013

Labels: -Cr-Content Cr-Blink-Forms
Owner: tkent@chromium.org
Status: WontFix
This is an expected behavior since Chrome 30.  Clicking a button focuses on the button, and the button has :focus style.
Please contact to the web page author if you think this is wrong.

Comment 3 by aoeuid@gmail.com, Oct 4 2013

Umm, this is far too obtrusive. The outline on every button seriously affects the look of the webpage — even here, on Google Code. Disabling the outline, however, also affects <tab>ing, where the outline is the only indicator of focus.

Seems like a related bug:
https://code.google.com/p/chromium/issues/detail?id=25518

Focus ring appears on mouse interactions (as opposed to only when tabbing through items):
https://bugzilla.mozilla.org/show_bug.cgi?id=418521



Out of interest, why is this the behaviour for buttons but not links?
Furthermore, this only happens on buttons when the button’s CSS background is set to `none: http://jsbin.com/oJUNAkaT/2/edit

Comment 6 by aoeuid@gmail.com, Feb 1 2014

Can this be re-opened? I've got a strong feeling this is causing serious accessibility degradation on the web and the longer it remains the larger the damage.

Given that styling buttons is such a widespread practice and a blurry outline on mere clicking will likely cause developers to disable outlines entirely, we'll be left with forms that show no indication that you've tabbed to buttons. At best. At worst we'll be without all focus outlines.
Status: Available
I think we should revisit this.

I agree with comment #6 - people are removing the focus style from elements to avoid this issue, which hurts accessibility overall. http://stackoverflow.com/questions/19053181/how-to-remove-focus-around-buttons-on-click is just one example of advice to remove the focus ring to avoid this issue.
Labels: Cr-UI-Accessibility

Comment 9 by tkent@chromium.org, Jul 27 2015

Labels: -Cr-Blink

Comment 10 by coc...@gmail.com, Aug 25 2015

In agreement with #3, #6, and #7. I'm getting requests from the UX team to remove the outline on click... when in fact that's out of my hands. Setting the focus state to outline: 0 is not a viable alternative since it hurts accessibility.

Any chance this can get looked at again?

Comment 11 by coc...@gmail.com, Aug 25 2015

Also, in response to #5, it looks like the focus ring is showing up on click when the background property has been set to any value, not just "none".

Leaving background untouched, it correctly does not show the focus ring on click.

Comment 12 by tkent@chromium.org, Aug 26 2015

Labels: -OS-Mac Cr-Blink-Focus
Owner: ----
At this moment we can do nothing for Chromium/Blink.  We need to focus on an element when it is clicked, and it should be matched to :focus.

Web authors can implement the desired behavior by small JavaScript code.  Example: https://chromium.googlesource.com/chromium/src/+/master/ui/webui/resources/js/cr/ui/focus_outline_manager.js

The best solution would be the CSS standard introduces a pseudo selector like :focused-by-pointer or :focused-by-keybaord.

Comment 13 by aoeuid@gmail.com, Aug 26 2015

Well, how does Firefox handle this internally? They _don't_ apply `:focus` on a mouse click at least. Only when you tab to buttons.
Apparently this has already been fixed. See #5 in https://code.google.com/p/chromium/issues/detail?id=521305#c5.
Cc: rob@robwu.nl
Status: Fixed
Ok, let's close this as it's already fixed.

Adding rob@ in cc so he could verify.

Comment 16 by rob@robwu.nl, Oct 1 2015

I cannot verify the bug because I don't see a clear bug description here.
Status: Available
Summary: Outline should not appear on elements focused by mouse (was: Outline appears on focused element all the time)
The bug is, for example,

1. open data:text/html;charset=utf-8,<button type=button style="background:gray">Button</button>
2. Click on the button by a mouse (not TAB focus navigation)

Expected: The button has no focus ring
Actual: The button has focus ring

So, we don't fix this yet.

Comment 18 by rob@robwu.nl, Oct 2 2015

I've tested the following in several browsers (http://jsfiddle.net/t9g1403n/1/show), by clicking on the button and moving the mouse away (to avoid :hover effects):
1: <button>Button default</button>
2: <button style="background:gray">Button gray</button>
3: <button class=outline-focus>Button :focus outline</button>
   <style>.outline-focus:focus { outline: 1px solid red; }</style>

In all browsers, button 2 looks different from 1 and 3 (button 1 and 3 has a "native" style, while 2 looks like an ugly styled button with a custom background).

Has focus effect, for each of the buttons?
- Safari 5.1 (Windows 7-10) : N N N (note1)
- Safari 9 (OS X 10.11)     : N N N (note1)

- IE Edge (Windows 10)      : N N Y
- IE 11 (Windows 7, 8.1, 10): N Y Y (note2, note3)

Firefox follows the platform conventions.
- Firefox 41 (Linux)        : Y Y Y (note2, note4)
- Firefox 41 (Windows 10)   : Y Y Y (note2, note4)
- Firefox 41 (Windows 7-8.1): Y N Y (note3)
- Firefox 41 (OS X 10.11)   : N N N

Chrome has a uniform styling across platforms.
- Chrome 47 (Linux)         : N Y Y
- Chrome 47 (Windows 10)    : N Y Y
- Chrome 47 (OS X 10.11)    : N Y Y

Opera Presto is no longer used, but I'm showing it because it's a different rendering engine.
- Opera 12.16 (Windows 8.1) : Y Y Y (note2)
- Opera 12.15 (OS X 10.11)  : Y Y Y (note2)

* note1: Does not focus the buttons, let alone activate :focus upon click, even after enabling "Press tab to highlight each item on a webpage".
* note2: button 2's visual focus differs from button 1's focus effect (shown by clicking on button 1 or tabbing to it if clicking does not activate a focus effect).
* note3: IE's visual focus on button 2 is subtle: the inner border becomes slightly thicker.
* note4: Firefox's visual focus is subtle: a dotted box inside the button.


CONCLUSION
There is no consistency in focus effects upon click among browsers, but the browsers made by OS vendors (IE Edge, OS X) seem to prefer no focus effect after clicking a button. Firefox attempts to match platform conventions (https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-focusring).
Therefore I think that we should indeed change Chrome's behavior, and not show the focus ring after clicking the button (probably with logic similar to my a[href]:focus changes in  bug 388666 ).


<button>s are not the only form element, are there any other elements that need such visual changes?

Comment 19 by pdr@chromium.org, Oct 4 2015

Cc: aboxhall@chromium.org rbyers@chromium.org
Windows 10 seems pretty inconsistent. The newer Windows UWP dialogs (e.g., windows 10 settings) never show focus on mouse down. Other programs like Paint will not show focus in some cases (open file dialog accessed via the ribbon button) but will in others (open file dialog accessed via ctrl+o). The Windows 10 start menu works more like UWP/OSX and does not show focus on mouse down. Firefox/Opera may not have made the same decision if Windows 10 had been out back then.

Android also works like UWP/OSX.

How do folks feel about contacting the Edge and Firefox teams about unifying on the UWP/OSX behavior, both for {browser,platform} consistency and so users don't break accessibility due to this?
Labels: Cr-Blink-Paint
+1, let's improve compat on this.
Some discussions in WICG:

http://discourse.wicg.io/t/detecting-users-dont-require-visible-focus-rings/804 Detecting users don’t require visible focus rings

http://discourse.wicg.io/t/exposing-a-users-input-modality/1067 Exposing a user's input modality

Labels: -Cr-Blink-Paint
Removing Cr-Blink-Paint since this is not really a paint bug.

Comment 23 by tkent@chromium.org, Jun 16 2016

Cc: tabatkins@chromium.org
Status: ExternalDependency (was: Available)
Tab proposed :focus-ring.
https://lists.w3.org/Archives/Public/www-style/2015Sep/0226.html

We can implement it so that it matches only when an element was focused by keyboard.
We'd like to implement it when it is added to the CSS selectors specification.

Comment 24 by tkent@chromium.org, Mar 26 2017

Labels: Needs-BlinkIntent
Status: Available (was: ExternalDependency)
:focus-ring is on the draft.  We should send intent-to-implement (and ship).

https://drafts.csswg.org/selectors/#the-focusring-pseudo

Labels: NewComponent-Accessibility-Blink NewComponent-Accessibility
Components: Blink>Accessibility
Components: -UI>Accessibility
Labels: -newcomponent-accessibility-blink -newcomponent-accessibility
Labels: triage-dominic
Labels: -Via-Wizard -triage-dominic
https://github.com/wicg/focus-ring

Components: Blink>HTML>Focus
Components: -Blink>Focus
Project Member

Comment 32 by sheriffbot@chromium.org, Oct 1

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
:focus-visible is in the spec, and implemented in Chrome now. @aboxhall, it seems like we can close this?
Owner: aboxhall@chromium.org
Status: Assigned (was: Untriaged)

Sign in to add a comment