Accessibly Hiding Focus Outlines

This text was up to date on 13 August 2020 to incorporate efficiency issues with the Javascript resolution.

By default, browsers present styling for components once they obtain focus. This varies from browser to browser, however is usually a top level view round a component. In Chrome, the main target type manifests as a blue glowing define. In Firefox it’s a skinny dotted define that inherits the factor’s color.

The main target ring (because it’s generally recognized) needs to be considered a characteristic, not a bug. It’s particularly helpful in case you’re navigating an internet site utilizing a keyboard somewhat than a mouse: when tabbing via components, the consumer can see precisely the place they’re on a webpage, and which factor is at the moment in focus. This text by Eric Bailey does an awesome job of explaining why focus types are necessary. Sadly, its advantages are sometimes poorly understood by purchasers and designers. Builders are ceaselessly requested to take away the main target define by others who consider it to be unintentional, or ugly. Personally, I’ve fought this battle many time, and never at all times efficiently.

Styling with CSS

Should you’re compelled to cover the browser’s focus ring, the least you are able to do is present an alternate focus type. We are able to use CSS to offer focus types which might be extra in step with your web site’s model. We are able to type these utilizing the :focus pseudo class, like so:

enter:focus {
  define: 2px strong deeppink;
}

(Eric’s article additionally goes into further choices for styling, like :focus-within.) However that always depends on a designer offering focus types which might be no less than as accessible because the browser defaults (e.g. they supply a better seen change than merely a change of color, which individuals with color blindness or different visible impairments might have hassle perceiving), and typically require a consumer to signoff on them. Typically there is a chance to again to the designer to request accessible focus types, however different occasions you’re not ready to delay the challenge.

An accessible different with Javascript

Lately, my colleague Carl Hughes pointed me to an answer from Spotify developer José M. Perez, which makes use of Javascript to cover the main target ring initially, then show it solely when a consumer interacts with a key press, by appending a category to the doc root:

doc.addEventListener('keyup', operate (occasion) {
  /* if secret is tab */
  if (occasion.which === 9) {
    doc.documentElement.classList.take away('u-no-focus-outline')
    doc.documentElement.classList.add('u-focus-outline')
  }
})

Then we are able to use CSS to cover the define is the doc has the “no focus” class.

.u-no-focus-outline *:focus {
  define: none;
}

After all, you may not wish to take away the main target ring on each kind of factor, and you’ll type particular components in line with desire.

Bettering the accessibility

My colleague modified the code barely in order that the category is added with JS. That method the web site will nonetheless be accessible if JS fails to load, as the main target types will stay intact. Moreover, I made a few small modifications: Switching the deprecated occasion.which property to occasion.code, and appending the category to the <physique> tag as an alternative of the doc root (which is only a private desire):

doc.physique.classList.add('u-no-focus-outline')

doc.addEventListener('keyup', operate (occasion) {
  if (occasion.code === 9) {
    doc.physique.classList.take away('u-no-focus-outline')
    doc.physique.classList.add('u-focus-outline')
  }
})

This resolution appears to be easy, elegant, and satisfies the consumer’s requests, whereas sustaining accessibility. I’m nearly aggravated I by no means considered it! It may be coupled with customized CSS styling in your focus states too, so that everybody will get expertise that’s in step with the model. There could also be different points I haven’t thought of, so in case you’ve come throughout any pitfalls with this methodology I’d love to listen to about them. In any other case, I can see no motive to not use it in manufacturing.

Learn the unique weblog put up right here.

Future styling with :focus-visible

The :focus-visible CSS pseudo class is, in reality, designed to unravel this very downside. We are able to use it to focus on solely components which might be centered with a keyboard. Sadly, browser assist is at the moment very poor. As Eric’s article factors out, there’s a polyfill, however I’d personally favour the above resolution over the additional growth overhead {that a} polyfill provides.

Lastly, I wish to level out that focus types may be very helpful in various methods that will not have been thought of by a designer or consumer, even for mouse customers, and eradicating them nonetheless may not be one of the best thought. From the article:

One other level to contemplate is that focus types may be fascinating for mouse customers. Their presence is a transparent and unambiguous indication of interactivity, which is a superb affordance for individuals with low imaginative and prescient situations, cognitive considerations, and people who find themselves much less technologically adept.

Personally, I discover it extremely helpful to have clear focus types on kind inputs, which makes could be very apparent which subject you’re at the moment filling in. So suppose twice earlier than you take away these focus outlines – the browser provides them for a motive!

Sources

• :focus-visible and backwards compatibility by Patrick H Lauke
• Specializing in Focus Kinds by Eric Bailey
• One among my favorite accessibility testing instruments: The Tab Key by Guide Matuzovic