Created attachment 427251 [details] Example This comes from a discussion in a different bug: https://bugs.webkit.org/show_bug.cgi?id=225075 Trying to summarize the topic it's about one sentence of the :focus-visible spec and how it's implemented on the different browsers. The spec text is (https://drafts.csswg.org/selectors/#the-focus-visible-pseudo): "If the user interacts with the page via keyboard or some other non-pointing device, indicate focus. (This means keyboard usage may change whether this pseudo-class matches even if it doesn’t affect :focus)." The usual example for this case is a DIV with tabindex, so it can be focused. You click on the DIV and initially you don't match :focus-visible. Then if you type a letter or ENTER or some other key, you start matching :focus-visible. However if you just do "Ctrl + +" to zoom the page, you don't start matching :focus-visible. When you're in an INPUT, this is not relevant at all, as you always match :focus-visible. So you don't care about the key strokes on that case. The 3 implementations differ right now on what they do here. Imagine that we've just clicked a DIV with tabindex and it's focused but not matching :focus-visible: * Chromium: * Typing "a": Change. DIV matches :focus-visible * Typing "Ctrl": No change. DIV doesn't match :focus-visible * Typing "Ctrl + y": No change. DIV doesn't match :focus-visible * Typing "Shift": Change. DIV matches :focus-visible * Typing "Shift + a": Change. DIV matches :focus-visible * WebKit: * Typing "a": Change. DIV matches :focus-visible * Typing "Ctrl": No change. DIV doesn't match :focus-visible * Typing "Ctrl + y": No change. DIV doesn't match :focus-visible * Typing "Shift": No change. DIV doesn't match :focus-visible * Typing "Shift + a": Change. DIV matches :focus-visible * Firefox: Firefox doesn't change anything in any of the cases. The element keeps not matching :focus-visible after any key stroke. The question here is if we think this is or not a correct behavior. One option could be that WebKit follows Firefox and doesn't change :focus-visible on key strokes. Ryosuke please share your feedback on the topic. Thanks.
FWIW, the only distinction here between the existing ones is the pressing of a bare shift. I think that we know that _generally_ we wouldn't want control characters to light it up because they are used too often and for too many things by browsers and apps - iirc we even had some feedback about this earlier with the polyfill (from slack I think). To answer a quesition from the linked bug that is related - ~"why is it desirable?"... Knowing the "right" answer is extremely complex - :focus just said "it always matches" and creates way too many cases where this feels bad non-sequential focus users, ultimately disinecntivizing use at all. Where there are questions focus-visible tends to err the other way, but provide a few escape hatches for keyboard users to allow them to "force" showing the indicator to see where they are. Most of the time tab/shift+tab can be used by keyboard users for this purpose, but there are other cases where that is either awkward or just wont work. I believe shift to toggle was left as an explicit user affordance in chromium as one of these means.
FWIW, the only distinction here between the existing ones is the pressing of a bare shift. It would be worth matching on the others. To answer a queition from the linked bug that is related - ~"why is it desirable to do any of these?"... Knowing the "right" answer is extremely complex - :focus just said "it always matches" and creates way too many cases where this feels bad to the majority of non-sequential focus users. This ultimately leads to disinecntivizing use at all. Where there are questions focus-visible tends to err the other way. We know several cases where there are plenty of places where there are clear answers. _Generally_ we wouldn't want control characters to light it up because they are used too often and for too many things by browsers and apps - iirc we even had some feedback about this earlier with the polyfill (from slack I think). Still, getting there will be 'false negatives' so there are intentionally a few escape hatches for keyboard users to allow them to "force" showing the indicator to see where they are. Most of the time tab/shift+tab can be used by keyboard users for this purpose, but there are other cases where that is either awkward or just wont work. I could be wrong on this, but I believe shift to force toggle was left as an explicit user affordance in chromium as one of these means. That said, if we didn't match on that, I don't think that is critical. There can and will be platform differences and if, through real use, there appears to be something that is universally advantageous or less so that is like this, I feel like that can align later.
(In reply to Manuel Rego Casasnovas from comment #0) > Created attachment 427251 [details] > Example > > This comes from a discussion in a different bug: > https://bugs.webkit.org/show_bug.cgi?id=225075 > > The usual example for this case is a DIV with tabindex, so it can be focused. > You click on the DIV and initially you don't match :focus-visible. That doesn't match what we do today. We show the focus ring immediately when the user clicks on a focusable element. > Then if you type a letter or ENTER or some other key, you start matching > :focus-visible. > However if you just do "Ctrl + +" to zoom the page, you don't start matching > :focus-visible. I really don't understand where this rule comes from.
https://bugs.webkit.org/show_bug.cgi?id=225148(In reply to Ryosuke Niwa from comment #3) > (In reply to Manuel Rego Casasnovas from comment #0) > > Created attachment 427251 [details] > > Example > > > > This comes from a discussion in a different bug: > > https://bugs.webkit.org/show_bug.cgi?id=225075 > > > > The usual example for this case is a DIV with tabindex, so it can be focused. > > You click on the DIV and initially you don't match :focus-visible. > > That doesn't match what we do today. We show the focus ring immediately when > the user clicks on a focusable element. That's the main thing :focus-visible wants to address. As all browsers were showing a focus ring just after a click on a DIV with tabindex, people started to add rules like ":focus { outline: none; }". But these rules are very bad from an a11y point of view, as when users use keyboard navigation to focus that DIV, they won't get any focus ring either. With :focus-visible you'll only see the focus ring when it's actually useful (keyboard navigation) and people won't need to use things like ":focus { outline: none; }". > > > Then if you type a letter or ENTER or some other key, you start matching > > :focus-visible. > > However if you just do "Ctrl + +" to zoom the page, you don't start matching > > :focus-visible. > > I really don't understand where this rule comes from. I guess this is to allow users know where the focus is by typing some key.
(In reply to Manuel Rego Casasnovas from comment #4) > https://bugs.webkit.org/show_bug.cgi?id=225148(In reply to Ryosuke Niwa from > comment #3) > > (In reply to Manuel Rego Casasnovas from comment #0) > > > Created attachment 427251 [details] > > > Example > > > > > > This comes from a discussion in a different bug: > > > https://bugs.webkit.org/show_bug.cgi?id=225075 > > > > > > The usual example for this case is a DIV with tabindex, so it can be focused. > > > You click on the DIV and initially you don't match :focus-visible. > > > > That doesn't match what we do today. We show the focus ring immediately when > > the user clicks on a focusable element. > > That's the main thing :focus-visible wants to address. > > As all browsers were showing a focus ring just after a click on a DIV with > tabindex, people started to add rules like ":focus { outline: none; }". But > these rules are very bad from an a11y point of view, as when users use > keyboard navigation to focus that DIV, they won't get any focus ring either. > > With :focus-visible you'll only see the focus ring when it's actually useful > (keyboard navigation) and people won't need to use things like ":focus { > outline: none; }". Are you saying that the intent is to not show the focus ring when the user clicks on an element with tabindex? I don't think we want to do that. > > > Then if you type a letter or ENTER or some other key, you start matching > > > :focus-visible. > > > However if you just do "Ctrl + +" to zoom the page, you don't start matching > > > :focus-visible. > > > > I really don't understand where this rule comes from. > > I guess this is to allow users know where the focus is by typing some key. I don't think detecting Control key like described in https://bugs.webkit.org/show_bug.cgi?id=225148#c0 makes a whole lot of sense. What makes more sense to me is deciding it based on whether some event handler or the default event handler did something in response to a key event or not. Namely, EventHandler::internalKeyEvent returned true.
(In reply to Ryosuke Niwa from comment #5) > (In reply to Manuel Rego Casasnovas from comment #4) > > https://bugs.webkit.org/show_bug.cgi?id=225148(In reply to Ryosuke Niwa from > > comment #3) > > > (In reply to Manuel Rego Casasnovas from comment #0) > > > > Created attachment 427251 [details] > > > > Example > > > > > > > > This comes from a discussion in a different bug: > > > > https://bugs.webkit.org/show_bug.cgi?id=225075 > > > > > > > > The usual example for this case is a DIV with tabindex, so it can be focused. > > > > You click on the DIV and initially you don't match :focus-visible. > > > > > > That doesn't match what we do today. We show the focus ring immediately when > > > the user clicks on a focusable element. > > > > That's the main thing :focus-visible wants to address. > > > > As all browsers were showing a focus ring just after a click on a DIV with > > tabindex, people started to add rules like ":focus { outline: none; }". But > > these rules are very bad from an a11y point of view, as when users use > > keyboard navigation to focus that DIV, they won't get any focus ring either. > > > > With :focus-visible you'll only see the focus ring when it's actually useful > > (keyboard navigation) and people won't need to use things like ":focus { > > outline: none; }". > > Are you saying that the intent is to not show the focus ring when the user > clicks on an element with tabindex? I don't think we want to do that. As I said, this is one of they key things behind :focus-visible, that when you click a DIV with tabindex you don't see a focus ring. Only when you use the keyboard to focus it, it shows it. If WebKit wants to always show a focus ring when a DIV with tabindex is focused via mouse click, then authors are going to start doing: :focus-visible { outline: none; } And that would disable it also for keyboard users which is bad for accessibility.
> As I said, this is one of they key things behind :focus-visible, that when you click a DIV with tabindex you don't see a focus ring. Only when you use the keyboard to focus it, it shows it. The spec for :focus-visible doesn't say anything about changing when the default focus ring appears. Rather, it's about giving authors a styling hook to style the focus ring only in exactly the cases where the browser would have drawn it by default. Or, to quote the spec: "While the :focus pseudo-class always matches the currently-focused element, UAs only sometimes visibly indicate focus (such as by drawing a “focus ring”), instead using a variety of heuristics to visibly indicate the focus only when it would be most helpful to the user. The :focus-visible pseudo-class matches a focused element in these situations only, allowing authors to change the appearance of the focus indicator without changing when a focus indicator appears." <https://drafts.csswg.org/selectors-4/#the-focus-visible-pseudo> Nowhere does the spec say anything about when UAs draw focus rings by default, or dictate a change to pre-existing behavior. Note in particular that the heuristic for when to draw a focus ring on a focused element may be platform-specific and even browser-specific.
(In reply to Manuel Rego Casasnovas from comment #6) > > As I said, this is one of they key things behind :focus-visible, that when > you click a DIV with tabindex you don't see a focus ring. Only when you use > the keyboard to focus it, it shows it. That's not mentioned anywhere in https://drafts.csswg.org/selectors-4/#the-focus-visible-pseudo. Where was this discussed? > If WebKit wants to always show a focus ring when a DIV with tabindex is > focused via mouse click, then authors are going to start doing: > :focus-visible { > outline: none; > } > And that would disable it also for keyboard users which is bad for > accessibility. Well, it's also bad not to show the focus ring on a focused element.
Yeah I know the spec doesn't say anything, and it gives total flexibility to each browser and platform for implementing different things. So it'd be totally ok from the spec point of view that WebKit still shows the focus ring when clicking a DIV with tabindex. What I meant is that the main purpose of having :focus-visible is precisely to avoid folks from doing things like ":focus { outline: none; }", which is widely used to avoid the focus rings in things like DIV with tabindex. So we could do something different in WebKit, and keep showing the focus ring when a DIV with tabindex is focused, but then people will start to do ":focus-visible { outline: none; }" and that wouldn't be really nice. Somehow defeating the purpose of having this feature. I know it's totally correct spec wise, but it'd be not what other browsers do, and neither what people are expecting from this feature I believe.
<rdar://problem/77550195>
> So we could do something different in WebKit, and keep showing the focus ring when a DIV with tabindex is focused, but then people will start to do ":focus-visible { outline: none; }" and that wouldn't be really nice. Somehow defeating the purpose of having this feature. Perhaps it should depend on the role or other functionality, more than the tag. For example, in the case of <div tabindex="0" role="textbox" contenteditable>, I would expect click-focus to show the focus outline. In the case of <div tabindex="0" role="button">, maybe not. Should the spec be more explicit about these details?
Maybe the distinction is as simple as "any click-focus that does not result in a visible text insertion caret"?
The spec text that is ambiguous to me is "supports keyboard input." For example, <select> (and custom ARIA equivalents) can support keyboard input in the form of arrow keys or typeahead to change selection. Does that ability necessitate `focus-visible` even though there is no text input "value" associated as with <input type="text">?
WebKit is already set up to not show focus rings for read-only text fields (following macOS platform convention, originally) so it would probably make sense to limit focus ring for arbitrary tabIndex elements to only ones that are contentEditable. But this might be under-inclusive of divs that should receive a focus ring when clicked. Making a focus ring appear when the user types in an already-focused element seems like a wrong and confusing behavior. The focus ring is supposed to tell the user where their typing will go. So only showing it after the user has typed something already misses the point. We should try to show it right away in places we believe will receive typing, even if the user clicked to focus it in the first place. However, making this change seems unrelated to the :focus-visible definition in the Selectors spec. The only things it has to say about the keyboard are in non-normative example sections. Incidentally, perhaps this UA stylesheet rule to suppress drawing a focus ring in some cases should instead be changed to be part of the definition of :focus-visible (and then other UA stylesheet rules should use :focus-visible instead of :focus). /* Read-only text fields do not show a focus ring but do still receive focus */ html:focus, body:focus, input[readonly]:focus, applet:focus, embed:focus, iframe:focus, object:focus { outline: none; }
> Maybe the distinction is as simple as "any click-focus that does not result in a visible text insertion caret"? I don't think that's right, or at least not complete. We have some built-in elements that do not show a caret but do receive a focus ring when clicked, e.g. <select> (both the pup-up menu kind and the list box kind). I agree though that at a minimum, any element where a caret would appear (which at least includes any contentEditable element) should get a focus ring by default.
One of the intentions of :focus-visible is to not match if someone mouse-clicks on a div (or other generic element) with a tabindex because developers often build custom controls using generic elements and when they unexpectedly show a focus ring on mouse click these same developer reach for :focus { outline: none; } which we really want to discourage. The spec attempts to explain that :focus-visible should not match when you mouse click an element with a tabindex, but does so in a way that maybe isn't explicit enough. Quoting from the spec: > If the element which supports keyboard input (such as an input element, or any other element that would triggers a virtual keyboard to be shown on focus if a physical keyboard were not present), indicate focus. This attempts to highlight the concept of "supporting keyboard input". Notably a div with a tabindex would not meet this criteria. > If the user interacts with the page via a pointing device (mouse, touchscreen, etc.) and the focused element does not support keyboard input, don’t indicate focus. The key phrasing here is "and the focused element does not support keyboard input". Since a div with a tabindex does not support keyboard input then it should not match :focus-visible when mouse-clicked. If, however, someone were to add contenteditable to the div, then it would meet the criteria and :focus-visible would match. > Perhaps it should depend on the role or other functionality, more than the tag. For example, in the case of <div tabindex="0" role="textbox" contenteditable>, I would expect click-focus to show the focus outline. In the case of <div tabindex="0" role="button">, maybe not. I think this is resolved by the point above. When designing the feature we often came back to the question of when is a custom control "button-like" versus "input-like". `contenteditable` seems to be a good indicator that something is "input-like", so :focus-visible will match if it's present. Otherwise it's assumed to be button-like. > The spec text that is ambiguous to me is "supports keyboard input." For example, <select> (and custom ARIA equivalents) can support keyboard input in the form of arrow keys or typeahead to change selection. Does that ability necessitate `focus-visible` even though there is no text input "value" associated as with <input type="text">? That's a great question and one that came up on GitHub (https://github.com/w3c/csswg-drafts/issues/5822). At the time we decided that it was one of those "the browser gets to decide" situations. So Chrome says that select is input-like and Firefox says that it's button-like. I don't personally have a strong opinion on which option is correct and am sort of curious to see which one users and developers prefer. > We should try to show it right away in places we believe will receive typing, even if the user clicked to focus it in the first place. I think(?) we all agree that if you're clicking on a control that can receive text input, or an element with contenteditable, that we should show a ring. If that's not happening maybe it's a bug in the implementation or perhaps I'm missing something 😅 > Incidentally, perhaps this UA stylesheet rule to suppress drawing a focus ring in some cases should instead be changed to be part of the definition of :focus-visible (and then other UA stylesheet rules should use :focus-visible instead of :focus). For what it's worth I think it is called out at the end of the :focus-visible spec that browser should switch the UA stylesheet to use the :focus-visible behavior: > User agents should also use :focus-visible to specify the default focus style, so that authors using :focus-visible will not also need to disable the default :focus style.
Regarding the questions around Ctrl and where all of that came from... The short answer is that Slack and Twitter wanted to use keyboard shortcuts to move focus to a different part of the page, but were surprised when that would then show a focus ring. For example, in Slack you can press a shortcut to open a drawer which receives focus, but they didn't want it to match :focus-visible. So we decided that if the user is pressing a keyboard shortcut that contained a meta/modifier key to move focus, then we would assume they're doing a keyboard shortcut and not match :focus-visible. However, if they were just using something like Esc (or any keypress without a meta/modifier key) to move focus, we would match :focus-visible. This allows you to hit Esc to close a dialog and see the focus indicator on the control that originally opened the dialog. I wrote a longer history here (https://gist.github.com/robdodson/af9ff157bbdfa6ab5f06fac46854f6ee) with links to various issues and PRs. We tried a few different options and eventually arrived at the current behavior. > What makes more sense to me is deciding it based on whether some event handler or the default event handler did something in response to a key event or not. Namely, EventHandler::internalKeyEvent returned true. I think this is a really interesting idea and not something we were able to do with the limitations of the polyfill. The reason I like this idea is because many apps have shortcuts that don't use modifier keys so it would still work for them. The one downside—if I understand correctly—is if the user is pressing Esc to close a dialog then it would not match when focus is returned to whatever control opened the dialog.
(In reply to Rob Dodson from comment #16) > > The spec attempts to explain that :focus-visible should not match when you > mouse click an element with a tabindex, but does so in a way that maybe > isn't explicit enough. Quoting from the spec: That is a rather consequential change. It's not really about adding a new CSS selector but rather affecting when a focus ring will be shown. It needs to be discussed separately from whether to add this CSS selector or not. > > If the element which supports keyboard input (such as an input element, or any other element that would triggers a virtual keyboard to be shown on focus if a physical keyboard were not present), indicate focus. > This attempts to highlight the concept of "supporting keyboard input". > Notably a div with a tabindex would not meet this criteria. This is a non-normative example. It has no bearing on what we implement. > > If the user interacts with the page via a pointing device (mouse, touchscreen, etc.) and the focused element does not support keyboard input, don’t indicate focus. > The key phrasing here is "and the focused element does not support keyboard > input". Since a div with a tabindex does not support keyboard input then it > should not match :focus-visible when mouse-clicked. If, however, someone > were to add contenteditable to the div, then it would meet the criteria and > :focus-visible would match. Ditto. > > We should try to show it right away in places we believe will receive typing, even if the user clicked to focus it in the first place. > > I think(?) we all agree that if you're clicking on a control that can > receive text input, or an element with contenteditable, that we should show > a ring. If that's not happening maybe it's a bug in the implementation or > perhaps I'm missing something 😅 The current implementation in Chrome and what's in WebKit's repository will show a focus ring when the user generates a non-control key keydown. We don't want to do that.
I wrote: > The spec text that is ambiguous to me is "supports keyboard input." For example, <select> (and custom ARIA equivalents) can support keyboard input in the form of arrow keys or typeahead to change selection. Does that ability necessitate `focus-visible` even though there is no [insertion caret or] text input "value" associated as with <input type="text">? Rob wrote: > The key phrasing here is "and the focused element does not support keyboard input". Since a div with a tabindex does not support keyboard input then it should not match :focus-visible when mouse-clicked. If, however, someone were to add contenteditable to the div, then it would meet the criteria and :focus-visible would match. Some examples that may still be ambiguous in the spec phrasing. <div tabindex="0" role="slider"> (with JS key handlers for arrows, home/end, etc) <div tabindex="0" role="listbox"> (or individually as "option" role) (with JS key handlers for arrows and typeahead filtering) Perhaps the way to move forward is with a more explicit definition of what it means to "support keyboard input"? Alternatively, Brian Kardell suggested we move forward by determining a list of what matches :focus versus :focus-visible. Potentially that would enumerate a number of these ambiguous examples.
So we need to figure out whether we want to implement this focus ring behavior as a part of :focus-visible or as a separate feature / runtime flag. It is somewhat surprising that enabling CSS selector feature suddenly changes the behavior of focus ring as well.
(In reply to Rob Dodson from comment #16) > One of the intentions of :focus-visible is to not match if someone > mouse-clicks on a div (or other generic element) with a tabindex because > developers often build custom controls using generic elements and when they > unexpectedly show a focus ring on mouse click these same developer reach for > :focus { outline: none; } which we really want to discourage. > > The spec attempts to explain that :focus-visible should not match when you > mouse click an element with a tabindex, but does so in a way that maybe > isn't explicit enough. Quoting from the spec: Everything you're quoting is from a non-normative Example, which starts with: "User agents can choose their own heuristics for when to indicate focus; however, the following (non-normative) suggestions can be used as a starting point". In other words, none of it is a requirement, it's just a suggestion of one possible way to do it. It's not even a SHOULD-level recommended requirement or a MAY-level optional requirement. If the spec intended to create a normative requirement, presumably it would have done so. All that said, I'm not sure we have strong feelings about what happens when the user clicks a tabindex-focusable generic element that is not obviously set up to receive typing. So long as behavior for built-in controls is not affected. > > > > We should try to show it right away in places we believe will receive typing, even if the user clicked to focus it in the first place. > > I think(?) we all agree that if you're clicking on a control that can > receive text input, or an element with contenteditable, that we should show > a ring. If that's not happening maybe it's a bug in the implementation or > perhaps I'm missing something 😅 This comment was in response to a suggestion that we should start showing a focus ring once a user presses a key after mouse-focusing an element. I'm not sure what problem that was trying to solve but it's not a good solution. > > > Incidentally, perhaps this UA stylesheet rule to suppress drawing a focus ring in some cases should instead be changed to be part of the definition of :focus-visible (and then other UA stylesheet rules should use :focus-visible instead of :focus). > > For what it's worth I think it is called out at the end of the > :focus-visible spec that browser should switch the UA stylesheet to use the > :focus-visible behavior: > > > User agents should also use :focus-visible to specify the default focus style, so that authors using :focus-visible will not also need to disable the default :focus style. It looks like the definition of :focus-visible in WebKit has not yet been aligned with the exceptions above, and the UA stylesheet has not been converted to use :focus-visible instead of :focus.
Slightly related to this old bug from 2013: https://bugs.webkit.org/show_bug.cgi?id=112968
Hi, I work in an e-commerce company and I'm working on enhancing our app's keyboard accessibility. I was referred to this issue as I am researching why Safari behaves differently on :focus-visible where Chrome and Firefox are more-or-less unified. I've read through the comments before, and understood some of the remarks are about whether readonly elements should pick up :focus-visible. I would like to supply our use cases as some examples, hope this will help provide some real-case scenarios for thought. The examples can be found here: https://focus-visible-examples.glitch.me/
(In reply to Wei from comment #23) > Hi, I work in an e-commerce company and I'm working on enhancing our app's > keyboard accessibility. I was referred to this issue as I am researching why > Safari behaves differently on :focus-visible where Chrome and Firefox are > more-or-less unified. > > I've read through the comments before, and understood some of the remarks > are about whether readonly elements should pick up :focus-visible. > > I would like to supply our use cases as some examples, hope this will help > provide some real-case scenarios for thought. > > The examples can be found here: https://focus-visible-examples.glitch.me/ I believe this is unrelated to ":focus-visible", the same problem happens without the runtime flag. The problem seems related with the combination of "outline" and "transition". See bug #173708.