Bug 242456 – Implement FocusOptions.focusVisible

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Emilio Cobos Álvarez (:emilio)]

See discussion at the URL.

[Alexey Proskuryakov]

It's a bit surprising that one would would want to draw focus outline without actually focusing? And if they do that, it would be super confusing to the user.

[Emilio Cobos Álvarez (:emilio)]

(In reply to Alexey Proskuryakov from comment #1)
> It's a bit surprising that one would would want to draw focus outline
> without actually focusing? And if they do that, it would be super confusing
> to the user.

Hm? That's not the point, you'd draw (or not) the outline only if the element gets focus. This only overrides the default behavior which is an heuristic.

[Emilio Cobos Álvarez (:emilio)]

I added a test for non-focusable elements to my patch.

[Radar WebKit Bug Importer]

<rdar://problem/97021844>

[Fotis Papadogeorgopoulos]

Hi! Have there been any updates on this? Having a way to prompt :focus-visible with programmatic focus would be very useful, to work around cases where the heuristics fall short. This is not a judgement, it’s just that whenever heuristics are involved, there should be a way to override them.

At Wolt (wolt.com), we ran into one such case when we updated our selectors to use :focus-visible. We wanted to align with browser heuristics, to ship less JS and be able to debug with the browser devtools (compared to the polyfill). 

We do focus trapping for our modals (and some other areas), where we intercept and `preventDefault` relevant keyboard events. When we do so, we instead call .focus() on the next item in the focus scope.

In those cases, Safari’s heuristics do not always work. If the user is only browsing with the keyboard, :focus-visible matches. However, if the user opens the modal with a pointer, but chooses to continue with the keyboard, then they do not get a :focus-visible style! This is arguably an accessibility failure regarding concurrent input mechanisms.

There are two bugs that seem related to this use-case:
https://bugs.webkit.org/show_bug.cgi?id=246591
https://bugs.webkit.org/show_bug.cgi?id=258987

However, I am making the case that if we had access to the `focusVisible` option, we would not need to wait for those bugs to be resolved.

I think the original GitHub discussion is exactly on point about identifying the need for this.

For posterity:

We introduced a lever to override :focus-visible by introducing a selector like this: `:is(:focus-visible, [data-force-focus-visible])`. We manually set `data-force-focus-visible` when calling `.focus()` inside the modal/focus scope. 

This works, but needs all components to be use it (since most components might be inside a modal),  runtime JS, co-ordination between teams, and a shared linting rule around `:focus-visible`. If we could rely on the `focusVisible` option, we could avoid all that :) 

I believe this same problem would show up for shared libraries, where co-ordinating a special selector to override :focus-visible might be even harder.

Please let me know if there is any other information that I can provide, to help motivate this.

[Luke Warlow]

Pull request: https://github.com/WebKit/WebKit/pull/32833

[EWS]

Committed 287959@main (20aaacc363ae): <https://commits.webkit.org/287959@main>

Reviewed commits have been landed. Closing PR #32833 and removing active labels.