Illustration of female developer working on a focus state with the text "something to :focus on" above her

Accessible Focus Indicators: Something to :focus on

Illustration of female developer working on a focus state with the text "something to :focus on" above her

Focus – that weird ring that shows up when your pinky misses caps lock and hits the tab key instead. It’s something that, until the last couple years, I didn’t think much about. Focus just wasn’t a big part of my design arsenal. But over time, as I worked on making my designs and design process more accessible, I found that the focus element not only provides user guidance and affordance but is an opportunity to explore your company’s whole approach to design.

This article will go into more advanced design techniques you can use to make your focus design more delightful. If you are still new to focus, check out our other article on it

Why does focus matter?

The key purpose of focus is to give a user guidance. Consider a user who can only use a keyboard to traverse your application. Would the focus match the visual style of the element or how the element behaves? Would it be visible at all? Focus’s job is to indicate what element the user is currently dealing with whether it’s a button or a block of text.

To a user with low or no vision, your application’s focus appearance may not matter as much as they will likely be using some assistive technology (AT), such as a screen reader, to help them navigate. However, for users that are able to see the screen, having a focus which is clearly visible and recognizable is important. It’s a pattern just like any other element you design and should adhere to your standards of consistency. Your focus shows users what is “clickable,” and it helps to identify what an element is.

Also, they’re fun to design. Having already designed hundreds of hover and click states, it was refreshing to suddenly discover and design this state I had somehow completely neglected. I began to see many of my “finished” patterns in a new light. Like many other pseudo-classes in CSS, it can be styled and overridden to your heart’s content—what you can do is limited only by your creativity.

Default Focus

Before you go crazy and start tossing fancy focuses on every pattern under the sun, think about what your default focus will be. This is the focus that will be applied to your entire application and will act as a fallback if you don’t specify a custom focus on an object. Your default focus should be clearly visible against your app’s background, it should pass color contrast guidelines and it should fit comfortably inside your color palette.

Let’s look at the default focus for our pattern library,

Our default focus is a saturated purple so that it shows up against a white (#ffffff) or off-white (#fdfdfe) workspace. It has an outline of 2px so it’s a bit more visible than a single 1px stroke, and there is a 2px offset so it doesn’t butt up against the text, such as when you focus a link.

Good Example

good example of focus box

Bad Example

Bad example of focus box

Tab around your application and notice where your focus looks really good and where it looks… um, less good. The places where the focus style feels out of place may be candidates for a custom focus.

Custom Focus

There are two instances in which we a use custom focus:

  1. When you want to give the focusable element special prominence (e.g. inputs or terminal buttons).
  2. When the default focus color doesn’t work against a specific background.

Let’s look at a few custom focuses we developed for Cauldron.

Field Inputs

This is a non-focused field from Cauldron.

This is a non-focused field from Cauldron

We wanted our field focus to have a distinct feel and to adjust to the field’s state. We chose to co-opt the color of field’s stroke and give it a gentle glow to indicate focus.

This non-focused field has a gentle glow

When the field is in the error state it gets a thicker stroke and red outline along with the supporting error text.

This focused field gets a thicker stroke and red outline with error text

When focus returns to an error field, the thick border diffuses back into a glow, giving visual continuity to the non-error focus state.

The focus on this error field diffuses into a glow.

We tried to make the focus state for fields feel like a natural extension of the pattern rather than something that overlays it.


This is a non-focused primary button from Cauldron:

Primary button

Our terminal button focus is a personal favorite not only because our front-end developer did a brilliant job implementing it but because it’s visually interesting and immediately identifiable as a focused state.

This button is our terminal button focus

Our secondary and error buttons use the same focus but have their color changed to appropriately match the text.

Second focus buttonError button

We made button focuses very visually distinct so they would pop out as they are used for terminal actions in our applications.


When a screen reader user enters into a form that has text or a header, that information needs to read out. Therefore the form would need to be focused in some way. This often shows up as the entire form being highlighted (sometimes invisibly?). When we have text areas, we use a couple different focuses to allow AT to read out without being visually messy.

For chunks of text that are going to be read out in a block, we use a left bar that appears in the gutter of the bounding object such as here in our alert. Once you tab out, it goes to the first tabbable object which, in this case, is the READY button.

Example chunks of text that has a left bar that appears in the gutter

For things like modals, where we have a form with a clear header, we use an underbar to indicate focus. It also moves to the first tabbable object after you hit tab which in this case would be First name.

Example of modal that uses under bar to indicate focus

Default Doesn’t Fit

There are times when you don’t want to make a custom focus but the default doesn’t fit the color of the background. I bet you can guess what you’re supposed to do: change the focus’ color. Below is an example from our toasts.

Good Example

Good example of alerts where the focus color passes color contrast

Bad Example

Bad example of alert where focus color doesn't pass contrast

Even though the close X uses the default focus, we needed to change the color to better pass color contrast and fit the color scheme better.

Things to Avoid

A few things to try and steer clear of when designing your focus:

  1. A focus that’s too discrete. I think we’ve all experienced the horrible dotted line focus that’s visible to practically no one. Focuses should be visually clear.
  2. Disappearing focus. This is often a z-index issue of some sort, and you see it a lot in tabbed menus. It’s important to check and make sure the focus of an element isn’t being cut off by something else.
  3. Visually mismatched focus. This one is certainly up to your design discretion, but don’t forget the old rule: if something feels off, it usually is.

We have a lot more examples of focuses we use on our Cauldron pattern site, and we’d love your feedback. If you’ve got any tips or tricks you find effective or even some examples of great focuses you’ve found, we want to hear about them.

update selasa

Comments 3 responses

  1. What are your thoughts on JavaScript libraries such as what-input, that dynamically detect when the user clicks with the mouse vs. presses keys on the keyboard. This allows the web page to hide focus styles conditionally, e.g., if the user clicks a button with the mouse.

  2. Šime, there are a couple of things I have found to be problematic with an approach that conditionally hides focus styles. Firstly, certain assistive technologies will fire mouse events from keyboard interactions (e.g. AT user presses ENTER and the AT programmatically fires a mousedown event) which would trick libraries like “what-input” into thinking that a mouse event occurred, when really it was a keyboard event in which focus should not be suppressed. In addition, there are mouse users who benefit from the presence of focus indication so leaving it out may cause other issues.

  3. Great article, thank you for sharing.

    When you say “non-focused” element, do you mean it lacks tabindex or just that it’s not distinguishable enough ? Was too lazy to check the source code 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *