Standardizing Focus Styles With CSS Custom Properties

Quickly test your project: Open your browser, use the Tab key only, and try navigating between interactive elements such as buttons, links, and form elements.

If you are a user with normal vision, you should be able to see the visual changes when the focus jumps between DOM elements. But if there is no visual change, or the change is minimal, then you can find a way to make a huge difference for your visitors.

This article will introduce a technique to more efficiently manage project focus styles using CSS custom properties and learn modern CSS focus selectors. First, let's understand why visible focus styles are so important.

Meet WCAG focus style standards

The visible focus status complies with the Web Content Accessibility Guidelines (WCAG) Success Standard 2.4.7 – Focus is visible. The "Understanding" document in 2.4.7 states the intention of this standard:

The purpose of this success criterion is to help the user understand which element has keyboard focus. It must be able to let the user know which element of multiple elements has keyboard focus.

In the upcoming WCAG 2.2, a new standard will be added to clarify “how obvious the focus indicator should be.” While still in the draft stage, getting familiar with and applying the guide in 2.4.11 – Focus Appearance (Minimum) is undoubtedly an active step to improve focus styles you can take today.

Manage focus styles with CSS custom attributes

One technique I started using this year is to include the following settings as early as possible on the main interactive basic elements in my cascading stylesheet:

 <code>:is(a, button, input, textarea, summary) { --outline-size: max(2px, 0.08em); --outline-style: solid; --outline-color: currentColor; } :is(a, button, input, textarea, summary):focus { outline: var(--outline-size) var(--outline-style) var(--outline-color); outline-offset: var(--outline-offset, var(--outline-size)); }</code>

This attaches custom properties, allowing you to flexibly customize certain parts of the outline style as needed to ensure that the focus remains visible when the element context changes.

For --outline-size , we use max() to ensure a value of at least 2px while allowing scaling based on 0.08em based on components (e.g., large buttons or links within the title).

The property you may not be familiar with here is outline-offset , which defines the space between the element and the outline. You can even provide a negative number to embed the outline, which is very useful for ensuring the contrast of the focus style. In our rule set, we set this property to accept an optional custom property --outline-offset so that it can be customized if needed, otherwise it will fall back to match --outline-size .

Contour appearance improvement

During my career, I have been asked to remove contours and have also removed contours myself because they are considered “unsightly.”

There are now two reasons why the contour should never be removed (except for accessibility effects):

1. In Chromium and Firefox, outline now follows border-radius ! ? This means you can consider removing any hack you may have used, such as using box-shadow to simulate it (this also positively affects accessibility, as it ensures that focus styles are not removed for Windows high contrast theme users).
2. With :focus-visible , we can ask the browser to use a heuristic to display the focus style only when an input pattern requiring visible focus is detected. In short, this means that the mouse user won't see them when clicked, and the keyboard user will still see them when Tab keys operate.

It should be noted that form elements always display focus styles—they are not limited by :focus-visible behavior.

So let's enhance our ruleset, adding the following to include :focus-visible . We will keep the initial :focus style we have defined for the old browser in case it won't be lost.

 <code>:is(a, button, input, textarea, summary):focus-visible { outline: var(--outline-size) var(--outline-style) var(--outline-color); outline-offset: var(--outline-offset, var(--outline-size)); }</code>

Due to the way browsers handle selectors they don't understand, we need to separate these rules, even if they define the same outline properties, we can't combine them together.

Finally, we also need this weird-looking :focus:not(:focus-visible) rule, which removes the regular focus style for browsers that support :focus-visible :

 <code>:is(a, button, input, textarea, summary):focus:not(:focus-visible) { outline: none; }</code>

It is worth noting that the latest versions of Chromium and Firefox have switched to using :focus-visible as the default way to apply focus styles on interactive elements and have recently been enabled as the default way in webkit, so it should be coming soon in Safari stable version! Our rules are still valid because we are customizing the outline appearance.

For more guidance on visible focus styles, I recommend Sara Soueidan’s wonderful and comprehensive guide on focus indicators, as it takes into account the upcoming 2.4.11 standard.

Focus style demonstration

This example demonstrates each of these interactive elements and how to apply custom settings using custom properties, including some changes to dark mode. Depending on your browser support, you may not see the focus style unless you use the Tab key, because :focus-visible is used.

Last thing: In terms of focus styles, button is a unique interactive element because it has additional considerations between its states, especially if you rely only on colors. For help, try using the palette generator in my project ButtonBuddy.dev.

The above is the detailed content of Standardizing Focus Styles With CSS Custom Properties. For more information, please follow other related articles on the PHP Chinese website!