loading...

re: Designing button focus states for better usability VIEW POST

FULL DISCUSSION
 

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

 

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)

 

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:

Code of Conduct Report abuse