Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: extend FocusOptions to allow specifying :focus-visible behavior. #7830

Closed
emilio opened this issue Apr 17, 2022 · 4 comments · Fixed by #8087
Closed

Proposal: extend FocusOptions to allow specifying :focus-visible behavior. #7830

emilio opened this issue Apr 17, 2022 · 4 comments · Fixed by #8087
Labels
addition/proposal New features or enhancements topic: focus

Comments

@emilio
Copy link
Contributor

emilio commented Apr 17, 2022

Right now, whether to show focus rings on programmatic focus is left up to the User Agent (see #6523 for some background etc).

The heuristics browsers use are mostly interoperable, but they do not cover all use cases. In Mozilla bug 1765083, someone details a use-case for forcing focus rings on programmatic focus (even when focus comes from the mouse). I think that use case is compelling, quoting:

Javascript is often used to validate a form and to set focus on an element that does not meet validation. Especially on complex forms, it can be hard for the end-user to draw their attention to the element without the aid of a focus ring.

It makes sense to show the focus ring even if the form submission was done via the mouse. Similarly, Firefox already has internal use cases for not showing the focus rings even when there hasn't been any previous focus move (which would show rings otherwise), see bug 1699259.

I think it would make sense to extend FocusOptions with something like this:

  boolean focusVisible;

To let authors override the focus ring heuristics that the UA implements.

How does something like that sound? I think it would be reasonably straight-forward to implement interoperably and would give more flexibility to web developers.

I think at least the option to force focus rings should be uncontroversial, as the result should never be less accessible than the alternative. The option to force remove focus rings might be a bit more debatable, but I think it probably makes sense.

cc @mrego @mfreed7 @rniwa

@mrego
Copy link
Member

mrego commented Apr 18, 2022

I guess trying to be smart about when to show it or not won't catch all the use cases, as we're seeing. So maybe this could be a solution for that problem.

I wonder what people that were involved in the :focus-visible definition and initial discussions think about this. So adding a few more people on CC @alice @robdodson @bkardell

@domenic domenic added the addition/proposal New features or enhancements label Apr 18, 2022
@domenic
Copy link
Member

domenic commented Apr 18, 2022

Any reason for the name focusRing instead of focusVisible?

Also, we don't need to make it nullable; it's a dictionary member so it would already be optional.

@emilio
Copy link
Contributor Author

emilio commented Apr 18, 2022

Any reason for the name focusRing instead of focusVisible?

Not really, I just made the name up. focusVisible sounds good to me :-)

Also, we don't need to make it nullable; it's a dictionary member so it would already be optional.

Ah, indeed. Updated the OP to account for that.

@craigkovatch
Copy link

craigkovatch commented Apr 19, 2022

I enthusiastically support this proposal! I just switched Tableau's internal UI library over to use :focus-visible and am now playing whack-a-mole with a bunch of edge cases that this would solve. For example WICG/focus-visible#268

IMO we should also expose the current "focus-visibility" as a property in FocusEvent, alongside.

emilio added a commit to emilio/html that referenced this issue Jul 7, 2022
emilio added a commit to emilio/html that referenced this issue Jul 8, 2022
@past past removed the agenda+ To be discussed at a triage meeting label Jul 8, 2022
moz-wptsync-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jul 11, 2022
As per:

 * whatwg/html#7830
 * whatwg/html#8087

Replace the internal preventFocusRing with the new flag.

Differential Revision: https://phabricator.services.mozilla.com/D151326

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1765083
gecko-commit: 570b38756541697f8b5c3b8084b5a2fb438eeca9
gecko-reviewers: smaug, pip-reviewers
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jul 12, 2022
emilio added a commit to emilio/html that referenced this issue Jul 12, 2022
moz-wptsync-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jul 12, 2022
As per:

 * whatwg/html#7830
 * whatwg/html#8087

Replace the internal preventFocusRing with the new flag.

Differential Revision: https://phabricator.services.mozilla.com/D151326

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1765083
gecko-commit: 570b38756541697f8b5c3b8084b5a2fb438eeca9
gecko-reviewers: smaug, pip-reviewers
domenic pushed a commit that referenced this issue Jul 13, 2022
aosmond pushed a commit to aosmond/gecko that referenced this issue Jul 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements topic: focus
Development

Successfully merging a pull request may close this issue.

5 participants