Designing button focus states for better usability

Let's say we're making a custom button. The designer hands off the design file, and we write some CSS to make it look exactly right. Pretty straightforward, right?

But wait — buttons have more than one state. The default state we just created looks good so far, but we need to make sure that it also looks noticeably different when it's focused.

Many people exclusively use keyboards to navigate, and rely on the focus state to know where they are on the page.¹

There's a huge variety of reasons why someone might use a keyboard over a mouse, and for many, using the mouse as a fallback just isn't an option.

When you navigate a page with the keyboard, you press tab to go through all the interactive elements on the page. If you have access to a keyboard now, go ahead and try it out. You should be able to easily see what's in focus.

If the focus state isn't visible (or hard to see), it's like trying to use a website with an invisible mouse cursor:

There's no way anyone would think that'd be okay to push to production! But when we don't pay attention to our focus states, that's exactly what we end up doing.

This affects real people in the same way the invisible-cursor example might affect you. If you're sighted, there's also a good chance that you, personally, might end up relying on these focus states as you age (assuming you don't already). Let's fix this!

Browser defaults

Browsers provide focus states by default. Here's what those look like on our custom button:

I don't have vision problems, but most of those are very hard for me to see. It's even worse for people with low vision — for them, there's no visible difference between these focus states and the default button state.

Designing a custom focus state

So what would we need to do to have a focus state that people can see? The main guidelines I use are:

1. If you're relying on color to signify a change in state, the color contrast ratio between the default color and the focus color needs to be at least 3:1².
2. Make sure that any outlines are thick enough to actually see. There aren't any official guidelines on this, but at least use something larger than 1px.

Here are some examples of accessible focus states:

Ahh, much better! I realize that a lot of people like things like this to be subtle, but it doesn't really matter what something looks like if you can't use it. This was just a quick proof of concept, so I'm sure there's more creative ways to work within these guidelines that will also fit the aesthetic.

I hope this is useful!

Related reading

• https://css-tricks.com/focusing-on-focus-styles/
• https://www.deque.com/blog/accessible-focus-indicators/
• https://hackernoon.com/removing-that-ugly-focus-ring-and-keeping-it-too-6c8727fefcd2
• https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html
• https://webaim.org/resources/contrastchecker/

---

1. https://www.w3.org/WAI/perspective-videos/keyboard/ ↩

2. https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html ↩

Comments

[Šime Vidas]

I like GOV.UK’s approach; they use a heavy outline in a unique color that is uniform across all their focus styles. This allows the user to look for that specific color whenever they move focus.

.govuk-button:focus {
    outline: 3px solid #ffbf47;
    outline-offset: 0;
}

design-system.service.gov.uk/compo...

[Elizabeth Schafer]

I agree — it seems much easier to follow focus when the style always looks the same. That makes a lot of sense but I don't think I'd ever had that thought. Thanks for pointing it out!

This is interesting though because while that outline looks bold and obvious to me, it actually doesn't have a high enough color contrast ratio in some cases (like when it's against a white background).

There's an issue in GitHub about it, but it was closed recently and I'm not sure why:
github.com/alphagov/govuk-frontend...

[Jack Buehner]

I think it might be because there is also an issue about meeting WCAG 2.1 standards: github.com/alphagov/govuk-design-s...

[Jerome Smadja]

Nice article. Thanks for writing this 👍
To add on that, there's a :focus-visible pseudo class (still in draft) developer.mozilla.org/en-US/docs/W... with which it's possible to add a focus style when not navigating with a pointing device. That's great because you can even have a bigger focus indication when navigating with keyboard.
Maybe I should write my first dev.to post article about that! :D

[Thibaut Allender]

I'm not a fan of :focus-visible as it leads to inconsistencies as soon as you start mixing input methods. It's not unusual for users to navigate with both the keyboard and the mouse at the same time, especially in forms.

[Jerome Smadja]

Leading to inconsistencies is actually the point of :focus-visible, because it lets you have more power on your focus management :)
In some cases, you probably don't want to show the users a fat border on an element they just clicked on (not much added value here). And to answer your comment on form inputs, :focus-visible will always apply on form inputs even though you use a mouse to focus the element. The rule being if the element triggers the keyboard on mobile it should apply :focus-visible.
I wrote a post about it ☝️ dev.to/wakooka/focus-style-for-key...

[Thibaut Allender]

The WICG issue you mention in this article actually raises a lot of concerns from users with disabilities, and my understanding is they came up with focus-visible to avoid the use of outline: none. Imho, and the OSX options are a great example, this should be handled at the OS or browser level like reduced-motion.

You can't really decide for the users if they need or want an outline on click or not. I'd rather not use :focus-visible and work on a focused state that benefits everyone (and doesn't look ugly).

To be honest, showing focus on elements that will load another page or change the content is not a big deal. If it's performant enough, you shouldn't see it for too long.

Links or buttons that stay on the screen after being clicked should have a clear focus state because you don't know what's the next step: switch to another tab, look for paperwork, come back and forget where you were if you start using the keyboard?

There are way too many possible scenarios, and assuming users will remember where the focus is because they just clicked that element is wrong.

Don't get me wrong, I totally understand why you would want to use focus-visible, but when working on governmental websites with strict accessibility requirements, this is probably not good enough.

[Elizabeth Schafer]

Thought you might be interested in this because focus styles are very inconsistent across browsers:

[Elizabeth Schafer]

Please do! I've seen :focus-visible in passing, but haven't tried using it. It definitely sounds like something that would make designers happy.

I'm wondering what the difference in usability is between the two. For example, I could see having a bold focus outline show up on click being potentially confusing, because it might look like you clicked a toggle button and selected something. But I'm not sure if there's a use case where you'd want to be able to clearly see the focus state while using a mouse.

Also interesting to note that not all browsers will place focus on a button when it's clicked: developer.mozilla.org/en-US/docs/W...

[Jerome Smadja]

Oh, thanks! I didn't know that browsers/os behave in a different way regarding focus when clicking on a button.

I'll try to write that post, I don't know :focus-visible in details just yet, that would be a good opportunity to learn (even though for now this is only in Chrome behind a flag)

[Thibaut Allender]

Thanks for the reminder, but while Example 3 and 4 indeed clearly change on focus, I'm not sure you'd understand they have focus in an isolated case, where they receive focus by default. It's a bit of an edge case, but you could think their default state was just designed like that.

Also, using an inverted and/or underlined style would force you to use a different focus style for inputs, and links, leading to confusion.

I know this is an article about button focus states, but you probably want to look at the bigger picture and think about a common solution, across all the focusable elements.

[Elizabeth Schafer]

Yes, great points! I actually made a similar comment recently in a discussion around upcoming WCAG changes around focus indicators (github.com/w3c/wcag/issues/812#iss...

At best you'd be able to maybe notice this change as it happens, but it'd be almost impossible to notice if you're coming back to a page without knowing where the focus is.

I agree that using a single style for everything (that's not obviously the default state) would be ideal.

[Trevor Saint]

I do this automatically when designing and developing websites without really thinking about it. I know it’s good practice and makes focus obvious.

I needed some rationale on why I do this exactly. Thankfully I found this article. I think you explain it very well and the example of how different browsers render focus is perfect!

Thank you.

[Lindsey Kopacz]

This is great, Elizabeth!

[Elizabeth Schafer]

Thanks, Lindsey! Your posts have been a great example to follow 😉