Add :focusring selector

[robdodson]

Adds support for :focusring, related discussion here: https://lists.w3.org/Archives/Public/www-style/2016Mar/0250.html

:focusring only matches an element if the element is currently focused and a focus ring or other indicator should be drawn for that element. This is extremely useful for accessibility.

As @tabatkins explained on the mailing list:

The main benefit of such a thing is that, today, if the default UA focus ring style does not work well with your site's theme, you're kinda screwed. You can manually write a :focus rule, but you can't predict when an element would have a focus ring drawn; you'll unfortunately start drawing focus rings when the user mouse-clicks a button. Using :focus-ring instead does the right thing automatically, triggering your styles only when the UA determines via heuristics that it should draw a focus ring.

[JanMiksovsky]

This would be great to have! This would address one of the big problems we've had implementing focus in web components.

The other big problem: there's no consistent way to ask that the standard focus appearance be applied to an element. The case we've hit here is a custom combo box that contains an input element and a dropdown button.

• We want the standard focus appearance to be applied to the entire combo box, not just the input element.
• At the same time, we actually want the input element to have the focus. As with many combo boxes (e.g., Windows combo boxes, Chrome's address bar), we don't need the dropdown button focusable, relying instead on arrow keys to invoke them.
• Hence, we want to tell the browser: Make this outer element look focused, don't make the actual input element look focused.
• Unfortunately, we're not aware of any standard CSS that lets us apply the browser's own focus appearance to an element.

Could you possible tackle this problem at the same time as :focusring?

[robdodson]

@JanMiksovsky if you're using shadow dom, have you looked into the delegatesFocus flag? It's a little confusing but here's a discussion on it: WICG/webcomponents#554

The tl;dr is that you can have :focus match on the containing element as well as the child that actually has focus.

[mathiasbynens]

typo: platform’s

[robdodson]

@mathiasbynens fixed, thank you!

[StommePoes]

\o/
I'm tired of writing

    <script>
      document.addEventListener('mousedown',function() {
        document.body.classList.add('mouseDetected');
      },false);

      document.addEventListener('keydown',function() {
        document.body.classList.remove('mouseDetected');
      },false);
    </script>

...

elements blah:focus {
  super awesome visible fugly focus styles;
}
.mouseDetected elements blah:focus {
nope nope nope
or the graphic designer will have my head
}

because while it does work well enough for most things on desktop, mobile is a whole screwy other world. Plus it's javascript for what feels like should be a pure styling thing.

[patrickhlauke]

Lazy: so this essentially matches the behavior/explanation of :-moz-focusring exactly, right? https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-focusring

[robdodson]

Yes, this is based on moz-focusring

On Nov 16, 2016 5:59 AM, "Patrick H. Lauke" notifications@github.com
wrote:

Lazy: so this essentially matches the behavior/explanation of
:-moz-focusring exactly, right?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#709 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABBFDSDgxpj1wlRuWWZokQF0Zyng8yOdks5q-wwrgaJpZM4KxmMy
.

[traviskaufman]

This would make a literal universe 🌠 of difference for Material Design Lite. Thanks for the excellent work on this. I was sad to see the input modality spec killed but I'm glad it's being resurrected and evolved into this.

[kaelig]

The mixed use of single and double quotes around the value of id might be a problem

[kaelig]

Should this class attribute value be wrapped in double quotes for consistency?

[robdodson]

I think the spec uses single quotes for these attributes https://github.com/robdodson/csswg-drafts/blob/06b54b7e135b6b823d8d9532c8b1bd21b9164ab5/selectors/Overview.bs#L695

[kaelig]

Should this class attribute value be wrapped in double quotes for consistency?

[robdodson]

double checking the spec I found examples of both "note" and 'note'. happy to do it all as double quotes though to make it consistent in the PR

[kaelig]

Yeah it's not consistent across all the specs. Looks like this particular spec leans towards double quotes, hence my suggestion.

[SebastianZ]

Regardless of the usefulness of the pseudo-class, I think it would be better called focusindicator or something like that, because it may not always be a ring that is shown.

Sebastian

[tabatkins]

First, thanks so much for writing this! I've been working on other projects for a good while and hadn't gotten around to doing this, so it's much appreciated. I'm going to do some heavy editting and then merge this.

Regardless of the usefulness of the pseudo-class, I think it would be better called focusindicator or something like that, because it may not always be a ring that is shown.

I think it's okay to call it "focus-ring" even if the indicator isn't always a ring; optimizing for simpler terminology is good.

[robdodson]

@tabatkins wonderful!! thanks so much for fixing it up 😸

[kaelig]

Good job on getting this in!

[benfrain]

I realise that :focusring will be fine. I agree that something more on the node may be advantageous. I'd favour something like :has-focus which declares exactly what the selector is for but leaves the author open to style that focus however is relevant for the UI.

[cookiecrook]

I think it's okay to call it "focus-ring" even if the indicator isn't always a ring; optimizing for simpler terminology is good.

What about :visible-focus or :focus-outline?

[cookiecrook]

Presumably this would allow authors to style things differently depending on how things were focused?

For example: If you called .focus() on a heading with tabindex="-1", it would not need the focus indicator. Is that correct?

Likewise, a mouse click on a button could move focus to that button but not trigger a focus outline since it was focused via the pointer? However if the focus was triggered via a Tab key press, it should show the outline/indicator. This would avoid the common anti-pattern of hiding all visible focus style because the designers want to avoid mouse-triggered visual artifacts.

[robdodson]

@cookiecrook

Presumably this would allow authors to style things differently depending on how things were focused?

Likewise, a mouse click on a button could move focus to that button but not trigger a focus outline since it was focused via the pointer? However if the focus was triggered via a Tab key press, it should show the outline/indicator. This would avoid the common anti-pattern of hiding all visible focus style because the designers want to avoid mouse-triggered visual artifacts.

Yes it is exactly for this use case.

For example: If you called .focus() on a heading with tabindex="-1", it would not need the focus indicator. Is that correct?

:focus-ring follows the UA's heuristic for when it decides to show a focus ring. In Chrome at least, if you focus() something with tabindex=-1 it will also show a ring. Having said that, I think there's room to refine that heuristic. For example, if you have a native <button> and you click on it with a mouse you will not see a focus ring. But if you style that button with something like border: none and then click on it, you will see a focus ring in Chrome, you will not in Safari. jsbin.

It may be a matter of figuring out what behavior we want from the UAs and working with them to ensure consistency.

[afercia]

Hello everyone. Seems to me part of the intent here is based on the assumption that a clear indication of the focus benefits only keyboard users. To me, that doesn't seem a correct assumption. Reading the "Understanding SC 2.4.7 (Focus Visible)" it's pretty clear the intent of that guideline is to make focus always visible for all users. Also for mouse users. Quoting:

Specific Benefits of Success Criterion 2.4.7:
This Success Criterion helps anyone who relies on the keyboard to operate the page, by letting them visually determine the component on which keyboard operations will interact at any point in time.
People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.

They're just two examples. The second one is not related to the device in use.

[bradkemper]

I think it is great to have this pseudo-class, but the name of it is dumb (no offense). It is describing what it looks like, I guess (or maybe it will "ring" like a bell for assistive tech?), instead of describing an understandable state.

It should be :keyboard-focus or :non-pointer-focus or something.

WRT focus for attention/memory limitations, I think that is why type-able controls, like text fields, show focus regardless of input method. But clicking or tapping a button isn't something that requires you to know that it has focus (and in the standard Mac UI, it doesn't even move the focus out of a text field). So that should be part of the heuristics.

That said, tabindex=0 does not really say much about whether focusing should be more like a text field or more like a button. I guess we could just continue to use :focus for text-fields. But it would be better if we had a css property (or @rule?) to make something focusable and to say what type of focus it should be.

[tabatkins]

Reading the "Understanding SC 2.4.7 (Focus Visible)" it's pretty clear the intent of that guideline is to make focus always visible for all users.

That guideline doesn't end up matching reality. Browsers have settled pretty conclusively on, for some types of elements, only visually indicating focus when it's obtained via keyboard. Requiring people that just want to restyle the focus ring to also fundamentally alter their page's UI affordances is not very useful. If we believed that focus rings should show on all focused elements, this should happen at the browser level first for all pages; then :focus and :focus-ring would just be synonyms that we support for legacy reasons. Until that happens, letting people just restyle the focus-ring and not otherwise alter how/when focus is visually indicated is useful, and that's what :focus-ring does.

---

I think it is great to have this pseudo-class, but the name of it is dumb (no offense).

It was named :focus-ring because that matches Moz's name (with fixed hyphen usage), and suggests, in a very clear way and simple way, when it'll match - when the focus ring would normally show up - and what it's intended for - restyling the focus ring. Any other name attempting to nail down the concept more semantically/abstractly loses this, requiring people to read spec text and grok the distinctions between this and :focus more explicitly. That sort of understanding is useful, no doubt, but it's not required to use :focus-ring correctly.

[patrickhlauke]

Reading the "Understanding SC 2.4.7 (Focus Visible)" it's pretty clear the intent of that guideline is to make focus always visible for all users.

For mouse users, the focus is always wherever they move their mouse to and click. This is different from keyboard users who need to know their current position within the document.

The problem with using straight :focus is also that it can end up confusing users. Take, for example, a series of buttons on a page that trigger some in-page behavior. They trigger every time the user activates them. Now a mouse user clicks one to trigger its specific behavior, and the :focus styles kick in. The button now looks visually different from the other buttons. However, it still functions exactly the same as before. This can confuse sighted mouse users who may think the button is now...different (maybe they think it's disabled, or that the button is some kind of on/off toggle, etc).

So, from an accessibility and usability issue, I would actually advocate for :focus-ring in these cases, and I would not fail this under WCAG 2.0 SC 2.4.7

additionally, note that most modern browsers are already silently optimising away their default focus indication (if not explicitly set by the page/author) on certain elements (like buttons) following a mouse activation. this just bridges the gap for author-defined focus styles to behave the same way.

[afercia]

For mouse users, the focus is always wherever they move their mouse to and click. This is different from keyboard users who need to know their current position within the document.

As I read it, the point of "Understanding SC 2.4.7" is that also people with attention deficit, etc., greatly benefit from a clear indication of focus, even if they're mouse users. This is the spirit of the guideline, unless I'm misreading it.

[afercia]

note that most modern browsers are already silently optimising away their default focus indication (if not explicitly set by the page/author) on certain elements (like buttons) following a mouse activation.

Yep I know, and this differs also across platforms. See for example current Firefox (53) on macOS (no focus indication on buttons) and on Windows (has focus indication). The current situation is pretty confusing but, as I see it, hiding focus on mouse activation on certain elements is against WCAG 2.0 SC 2.4.7. If things are going to change (I hope not), then WCAG 2.0 SC 2.4.7 should be updated to reflect the change?

[patrickhlauke]

Reading the actual SC itself

2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)

note the "has a mode of operation". When the user uses the keyboard, :focus-ring (and the silently optimised default focus indicator) are shown, thus fulfilling the requirements of the SC.

[afercia]

SC text are very synthetic :) I guess that's the reason why they're accompanied by an "Understanding".

People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.

Is clearly related to mouse users too.

[robdodson]

I don't think this needs to be seen as being only for keyboard users, quite the contrary, my hope is that :focus-ring could make it easier for users to define when they want to see focus indicators.
Here's the relevant bit of spec language:

an E element that has user input focus, and the UA has determined that a focus ring or other indicator should be drawn for that element

Since the UA gets to determine when to draw a focus ring, it means we now have access to some interesting options.

For example, today the UA checks to see if the user is using a keyboard to move around, if they are, then :focus-ring matches. But it could potentially include user configuration options as well. So one day the browser could expose a user preference for strong focus indicators. Checking that option would tell the UA that even if someone clicked on a control using the mouse, it should still match :focus-ring.

Personally I understand the argument for always displaying a focus indicator even on mouse click, but in practice I've found that these can be tough battles to win when your designers or project managers disagree. You may end up with very compromised focus styles that are subtle so as not to offend mouse users, but are therefore less useful to any user who wants a strong focus indicator. Or as @patrickhlauke pointed out, the focus indicator might be confusing to a mouse or touch user who wasn't expecting it. :focus-ring (hopefully) helps address this in a way that makes everyone happy.

[StommePoes]

We just got a complaint about a button showing its focus colours after some testing mouse users tested it. The button removes something from the page. Focus remains on the button (natch). The users thought they broke something (thought they made the button quit working) and the designers were, on the basis of that, asked to stop making the button change colour when clicked.

I think this is partially due to a combination of browsers acting a bit different regarding buttons than, say, links and inputs, and secondly because it's become super a la mode fashion hipster trend to go Material-Design-style where all the interactive feedbacks are so so so subtle that if you have anything less than the greatest-newest-sharpest monitor and eyeballs, you don't even see it. Example: faint shadow on clickable disappears when focussed. I think a lot of mouse users have simply not even noticed their buttons looked like a faintly different shade of blue all this time. And that's only IF designers and developers even bothered to add something other than :hover styles.

That's not to say there aren't any good cog reasons to show last-clicked or where focus is currently; but then that would need to be something any individual user could set (ideally in their browsers or OS and NOT via some crazy widget on the web page written by J Random Developer), because of that large majority of casual-mousers who get a disadvantage of being surprised, confused, and hitting against the element of least surprise.

[kizu]

Hi everyone, I've wrote an article today about having keyboard focus-only styles — http://kizu.ru/en/blog/keyboard-only-focus/ — alongside other things I've looked at how the existent :-moz-focusring behaves, and found out that it doesn't work for spans with added tabindex, while it works ok for buttons and links. In my opinion, the new property should work for any interactive element, not only for those that are initially interactive, as I can imagine people creating new interactive elements that are not semantically covered by links and buttons, but which should still have the same functionality in regards to focus styles and clickability.

[robdodson]

That seems pretty reasonable to me. I wonder if we could get someone from Mozilla to comment with their thoughts on this.

…

On Tue, Jun 27, 2017, 6:10 AM Roman Komarov ***@***.***> wrote: Hi everyone, I've wrote an article today about having keyboard focus-only styles — http://kizu.ru/en/blog/keyboard-only-focus/ — along other things I've looked at how the existent :-moz-focusring behaves, and found out that it doesn't work for spans with added tabindex, while it works ok for buttons and links. In my opinion, the new property should work for any interactive element, not only for those that are *initially* interactive, as I can imagine people creating new interactive elements that are not semantically covered by links and buttons, but which should still have the same functionality in regards to focus styles and clickability. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#709 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABBFDR92VA231gxgwk4udPESwPDhcACkks5sIP9cgaJpZM4KxmMy> .

[tabatkins]

The selector should match exactly and only those elements that, in the absence of author styling, would receive a native focus ring. If you want it to match in more situations, the correct approach is to get browsers to show a native focus ring in those situations. :focus-ring should never diverge from the native focus ring.

[kizu]

@tabatkins What is considered “native” focus ring? When an element has tabindex="0", is the focus ring on it in absence of any styles considered “native”?

[tabatkins]

It means there's a focus ring drawn on it by the browser. Yes, that particular example counts, at least in Chrome (I see a focus ring when I tab to the element).