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.
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: