Suppress the focus outline on elements that cannot be accessed via keyboard??

[jensimmons]

In Reboot, the base file for Bootstrap, they have this:

// Suppress the focus outline on elements that cannot be accessed via keyboard.
// This prevents an unwanted focus outline from appearing around elements that
// might still respond to pointer events.
//
// Credit: https://github.com/suitcss/base
[tabindex="-1"]:focus {
  outline: 0 !important;
}

Hmmmmm.

Comments?

[meyerweb]

I like the idea as described, but I definitely want to hear from primary keyboard users on this.

[frivoal]

When tabindex is -1, elements are still programatically focusable. Not showing focus indicators when that happens seems bad.

I suspect the perceived need for this is mainly due to the fact that :focus-visible wasn't a thing for the longest time, and that using :focus leads to many false positives, so this things is trying to eliminate some of them. But in the process, it's probably producing false negatives, which is arguably worse.

I too would like to hear from primary keyboard users, but I suspect this is a problem that will heal itself with time.

[alwillis]

According to the focus-visible spec, looks like what we want (at least for now) is

:focus:not(:focus-visible) { outline: 0; }

to remove the default focus style only if :focus-visible is supported; then we style :focus-visible to handle items that’ll get keyboard focus. Right now, only Chrome (behind a flag) and Firefox (as :-moz-focusring) supports :focus-visible.

Google created a focus-visible polyfill; their explainer document details the issues with :focus and why :focus-visible was created.

[frivoal]

That rule doesn't seem bad, but I don't think it changes anything compared to the browser's default behavior, so I am unsure how helpful it is.

[alwillis]

That rule doesn't seem bad, but I don't think it changes anything compared to the browser's default behavior, so I am unsure how helpful it is.

In the spirit of starting from a place of what we’d do if we were creating CSS today, we wouldn’t add an outline to elements that were never going to get keyboard focus, which is a side effect of :focus, which sometimes confuses non-keyboard users and annoys designers and developers, often leading them to disable :focus for everyone.

:focus-visible makes it so that only elements that can actually get keyboard focus get styled. The snippet from the specification :focus:not(:focus-visible) { outline: 0; } disables the default :focus outline only if :focus-visible is supported by the browser. That way, we don’t disable an important a11y feature in current browsers, while at the same time, disabling it for future browsers that support the improved option of :focus-visible.

[frivoal]

we wouldn’t add an outline to elements that were never going to get keyboard focus

right, but browsers don't either, so there's no need to disable a thing they don't do. :focus-visible works because it matches the elements on which the browsers would show an outline, which is a subset of :focus, even in browsers that don't support :focus-visible. :focus-visible is new syntax to access existing behavior.

:focus:not(:focus-visible) { outline: 0; } seems useful to override styles an author would have applied using :focus, since that's too broad, but browsers don't do that, and we're talking about a base stylesheet to use as the starting point of your site, so there's no author style to override.

[alwillis]

:focus:not(:focus-visible) { outline: 0; } seems useful to override styles an author would have applied using :focus, since that's too broad, but browsers don't do that, and we're talking about a base stylesheet to use as the starting point of your site, so there's no author style to override.

But browsers do have default styles for :focus which we may want to override only if the browser supports :focus-visible.

:focus-visible is new syntax to access existing behavior.

Based on reading the specification and watching Google’s I/O presentation What's new in web accessibility, I’d say there’s more going on than just a new syntax for accessing existing behavior.

Because :focus-visible uses browser heuristics and user preferences to determine if focus outlines should be shown—which :focus doesn’t do—:focus-visible gives designers, developers and users more control under what conditions they’ll see focus outlines. Users that need or want focus outlines will get them and users that don’t want or need them won’t.

Encouraging future users of CSS Remedy to support a11y in a more future friendly way seems like a good thing.

From the spec:

In this example, authors use a :not() pseudo-class to remove default user agent focus styling if :focus-visible is supported, and provide enhanced focus styling via :focus-visible.

:focus:not(:focus-visible) {
  outline: 0;
}

:focus-visible {
  outline: 3px solid var(--focus-gold);
}

[mirisuzanne]

:focus:not(:focus-visible) { outline: 0; }

The utility of this depends entirely on how browser add support for :focus-visible, which we don't know, because no browser has full support:

• No support :: No impact
• If browser add support without updating user-agent styles, this could remedy a new problem
• But browsers might update both at once, rendering it unnecessary

Currently there are two partial-support examples to look aat:

• Firefox has partial-support via :-moz-focusring, and user-agent styles updated to use that
• Chrome has partial-support behind a flag, without updated user-agent styles – likely because the styles don't update based on experimental feature flags

It seems like the safest future-proof solution might be adding the example code from the spec - but there is also a good chance it will never be needed.