This post was first published on my personal website.
One of the most important features of a website that is built with accessibility in mind is that it can be navigated with a keyboard. Most blind users and many users with motor disabilities rely on keyboard navigation, either with a standard keyboard or with a device that mimics the functionality of a keyboard. Providing strong visual indicators that highlight the element that currently has keyboard focus is therefore indispensable. In CSS, the focus styles for an element can be changed via the :focus
pseudo-class.
a:focus {
outline: 3px solid blue;
}
Hiding Focus Styles Is Bad Practice
Besides accessibility requirements, there are also design considerations to be made, though: For some users, a strong visual focus indicator once they click an element with a mouse or touch it with their finger can be irritating or feel “clunky”. Often, the focus highlight is only visible for a short time just before a page change occurs. This is an additional visual change in the interface that users have to process and understand. Without the knowledge that this highlight around the element is actually an accessibility feature, people might be distracted or irritated. Sometimes, it is even perceived as an error. And while some designers certainly are far more sensitive to the aesthetic qualities of an interface than its users – and would be well-advised to get used to a bit more accessibility-oriented, contrasted designs –, it is still relatable that focus indicators can feel like an intrusive break in an otherwise carefully balanced visual design.
Many clients and designers, therefore, insist that developers remove the focus styles altogether for purely aesthetic reasons.
a:focus {
outline: none;
}
This is bad. It is an uninformed decision that actively excludes people and should not be an acceptable solution in 2020 anymore. So don’t do that. We have to do better. But how?
One way out of this dilemma would be to cleverly design the focus state of an element so that it is perceived as a natural part of the transition from one state of the interface to the next. This, however, is not always easy or possible.
:focus-visible to the Rescue
Luckily, there is now another option: The :focus-visible
pseudo-class. According to the spec, “the intent of :focus-visible is to allow authors to provide clearly identifiable focus styles which are visible when a user is likely to need to understand where the focus is, and not visible in other cases.” Or, in other words, it lets you show focus styles only when they are needed, using the same heuristic that the browser uses to decide whether to show the default focus indicator:
/* Hide focus styles if they're not needed, for example, when an element receives focus via the mouse. */
:focus:not(:focus-visible) {
outline: 0;
}
/* Show focus styles on keyboard focus. */
:focus-visible {
outline: 3px solid blue;
}
Chrome 86 just shipped with support for :focus-visible, Firefox supports it via the :moz-focusring
pseudo-class since 2011 and Mozilla is currently working on adding support for :focus-visible
, too. So you can start using it now. And once more, progressive enhancement is your friend here. You can define regular focus styles for non-supporting browsers and then overwrite them for browsers that support :focus-visible
.
:focus {
outline: 3px solid blue;
}
:focus:not(:focus-visible) {
outline: 0;
}
:focus-visible {
outline: 3px solid blue;
}
You can try it out in this Codepen:
Note that :focus-visible
always applies in combination with :focus
. So if you inspect it in Chrome’s Developer Tools, for example, make sure to tick both boxes to see the appropriate focus styles.
A Polyfill for Older Browsers
If you need to support a wider range of browsers, including Safari, there is also a polyfill. It simply adds a focus-visible
class to all focused elements in situations in which otherwise the :focus-visible pseudo-selector would match.
Once the script is added to your page, the code looks much like in the examples above. The only difference is that now we are using classes to define the visible focus styles in our CSS:
.js-focus-visible :focus:not(.focus-visible) {
outline: none;
}
.js-focus-visible .focus-visible {
outline: 3px solid blue;
}
If you decide to use the polyfill, make sure to pay attention to how it behaves in combination with your existing focus styles. It might still be a valid choice to only use the polyfill until Safari also adds support for :focus-visible
. But regardless of which method you decide to use, it is fabulous that we now have a solution to a problem that was often “fixed” by developers and designers by making websites less accessible. :focus-visible
now offers a solution that is accessible and makes users, designers, and developers happy.
Further reading
- The Focus-Indicated Pseudo-class: :focus-visible, W3C CSS Selectors Level 4
- Giving users and developers more control over focus
- :focus-visible and backwards compatibility, by Patrick H. Lauke
- focus-visible Polyfill
- Can I use :focus-visible CSS pseudo-class?
- Navigate using just your keyboard, by Dave Rupert
- Focusing on Focus Styles, by Eric Bailey
Top comments (1)
focus is still the preferred UX over focus-visible IMO. The idea of the keyboard only user needs to be kicked into touch. Many accessible devices, eye tracking etc, act as pointer devices.
MDN even warns of the confusing behaviour with mixed type input.
I suggest we just need to style focus better.