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 straigh...
For further actions, you may consider blocking this person and/or reporting abuse
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.
design-system.service.gov.uk/compo...
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...
I think it might be because there is also an issue about meeting WCAG 2.1 standards: github.com/alphagov/govuk-design-s...
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
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.
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...
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.
Thought you might be interested in this because focus styles are very inconsistent across browsers:
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...
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)
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.
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...
I agree that using a single style for everything (that's not obviously the default state) would be ideal.
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.
This is great, Elizabeth!
Thanks, Lindsey! Your posts have been a great example to follow 😉