[Webkit-unassigned] [Bug 242456] Implement FocusOptions.focusVisible

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=242456

Fotis Papadogeorgopoulos <fotis.papadogeorgopoulos at wolt.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fotis.papadogeorgopoulos at wo
                   |                            |lt.com

--- Comment #5 from Fotis Papadogeorgopoulos <fotis.papadogeorgopoulos at wolt.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20231024/6021b71c/attachment.htm>