Summary: Implement the :focus-visible pseudo-class and effectively make
:-moz-focusring an alias of it.
This is intended to simplify the way authors deal with outlines to
improve accessibility. In particular, authors seem to hate outlines when
users focus stuff with the mouse, generally and so a lot of them do
:focus { outline: none }, which renders elements also inaccessible by
keyboard.
We have always exposed :-moz-focusring to represent Gecko's opinion on
whether something ought to have an outline, but that also didn't quite
have the desired effect (plus it required Firefox-specific selectors).
:focus-visible is supposed to be the standard version of :-moz-focusring
with a behavior that matches more author's expectations (but that users
can also customize).
To summarize current and upcoming behavior:
The behavior we're shipping depends on the platform, but for Windows is:
* If browser.display.show_focus_rings (default false), or a
Windows-specific setting (also default off) to always show outlines is
enabled, then all focused elements match :-moz-focusring.
* Otherwise (the default behavior) it matches all focused elements
only after the user has navigated once with the keyboard once in a given
tab.
If enabling this goes well (it's been enabled for a long while on
Nightly, with no known regressions, and it's early in the cycle so we
still have a bunch of time to fix issues if they arise) this will be the
new behavior (which is the current on Nightly):
* The first bullet point remains the same (with :focus-visible rather
than :-moz-focusring).
* <textarea>, contenteditable, and <input> elements that require
keyboard input or such always match :focus-visible if focused.
* For other elements, we follow the rules described in the spec (link
below), which are roughly that focus-visible matches for keyboard focus
but not mouse focus, and that whether programmatic focus matches depends
on whether the previously-focused element matched it.
* Additionally, if browser.display.always_show_rings_after_key_focus
is true (default false), then we keep the existing behavior of matching
all elements once keyboard navigation has occurred.
This should hopefully make developers happy and less prone to remove all
outlines on focus.
Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1445482
Standard:
https://drafts.csswg.org/selectors-4/#the-focus-visible-pseudo
Platform coverage: All
Preference: layout.css.focus-visible.enabled
DevTools bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1617608
Other browsers:
* Chrome: Shipped (M86)
* WebKit: N/A (
https://bugs.webkit.org/show_bug.cgi?id=185859)
web-platform-tests:
https://wpt.fyi/results/css/selectors?label=master&label=experimental&aligned&q=focus-visible
Cheers,
-- Emilio