Test case: https://cdpn.io/fvsch/debug/JjdNEjL/ZoABazdPJgGr

:focus-visible styles apply to elements focused with element.focus() in Firefox Nightly (75).

In Chrome (stable, 80), elements focused programmatically don't get :focus-visible styles.

I think it would be best to follow Chrome here to make :focus-visible more usable for web developers, but taking a step back I'm not 100% sure what browsers should do here.

One use case for element.focus() is, after clicking a button that reveals some content (say, a dropdown or a modal), moving the focus to that content:

• either to a container (<div tabindex="-1">...</div>)
• or to the first focusable element in that container

In that use case, we might want to show no focus style or very visible focus style depending on user needs.

So even if we could do HTMLElement.focus({ focusVisible: true }), as web developers we might be stuck because how do you know what a specific user needs here?

This was pretty intentional... How would a user know where the focus is? The focus could be anywhere, right?

In Chrome (stable, 80), elements focused programmatically don't get :focus-visible styles.

To be clear you need the experimental features flag, right? Stable chromium here throws for querySelector(":focus-visible"), which means they're not shipping the selector.

To be clear you need the experimental features flag, right?

Indeed, forgot I had this flag on.

This was pretty intentional... How would a user know where the focus is? The focus could be anywhere, right?

That's a tough problem, but what is going to happen is that when a client or product owner asks for a dropdown or modal or drawer menu, or any other feature where a button reveals content that is some way away from the toggle button in the DOM, if we want to manage focus like we should, we're going to do:

<button onclick="document.querySelector("#drawer-menu").focus()">Show Menu</button>

...

<div id="drawer-menu" tabindex="-1" style="outline: none">
  ...
</div>

Because the client or product owner won't live with a visible focus style (let alone a strongly visible one) on that element, and will file bugs about it.

Things get worse when closing the menu, because we probably want to move the focus back to the toggle button, but again the client or PO won't accept a very visible focus ring (from .toggle-button:focus-visible { /* obvious outline here */}), so our solution will be to… remove the focus-visible style.

Not sure it's going to be a win for accessibility.

It looks like this bug turned up as a CI test failure several months back.

For what it's worth, I'm inclined to agree with Florens' last update anyway; I also foresee clients taking issue with visible focus on dropdowns and toggles for mouse-users (which would be the case if programmatic focus applies :focus-visible). Plus, programatically focusing headers and other non-interactive elements is a strategy to simplify navigation for visitors using keyboards, screen readers, etc., and focus should not be visible in these cases.

The spec text has been improved a while ago, so I think we should do
this. This keeps the current moz-focusring behavior when the pref is
disabled, but when enabled it becomes effectively an alias of
focus-visible.

https://hg.mozilla.org/mozilla-central/rev/1e5d1f957f71
https://hg.mozilla.org/mozilla-central/rev/bc9221f63511

On MacOS (10.15.6) with Firefox Nightly 86.0a1, programmatically focusing a button still seems to apply :focus-visible (i.e. in Florens' example, both the button cases receive a pink outline when programmatically focused). Using the same Nightly version on Windows 10 behaves correctly (i.e. programmatically focusing a button doesn't trigger the visible focus state).

Is this difference intentional?

Yes, that difference is expected, because on mac clicking a button doesn't actually focus it (that's MacOS and Safari behavior we emulate, see accessibility.mouse_focuses_formcontrol in about:config).

So we don't ever detect the "there's a previously focused element" case. That's a bit unfortunate indeed, though it's a spec issue (if an issue). Mind filing it in https://github.com/w3c/csswg-drafts/issues/new? Feel free to cc me there (@emilio) and I can raise it for discussion.