-
Notifications
You must be signed in to change notification settings - Fork 235
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
2.4.7/2.4.11/2.4.12 Must a focus indicator always be displayed? #1387
Comments
I would say that the two links are not to be compared with each other but with each link's non-focused state, so they would pass.
Enlarging is still a change that can be measured. Moving could be as well but we would need to see the implementation.
I would regard those as separate from the focus. We had a focus for an internal app that when a button was focused there was a focus indicator that appeared as a rounded area behind the button (which was sufficient) but then that rounded area pulsed slowly from the focus state to a darker or lighter color (don't recall which because we asked that it be turned off as it was distracting).
This seems to be the same as the examples after your list. It can be measured but would be a pain to do. Hopefully enough of a pain that the designer would add a more-standard focus indicator. |
Proposed working group answer:
|
As the SC text has been updated since Detlev's draft, an update to be reviewed: The Working Group understands the importance of the focus indicator and that it should be displayed as long as the element has focus. The current SC text starts:
The "receive" term was used because there are things the user can do to obscure the focus indicator which are out of the authors control. E.g. scroll, or move a non-modal dialogue over the focused control. In order for the 'unobscured' bullet to work, this concept is necessary. However, 2.4.7 and 1.4.11 are still applicable after the the component has received focus, so any change to the focus indicator would still need to meet those criteria. |
I fail to see how 2.4.7 or 1.4.11 would guard against an implementation where the focus fades. 2.4.7 does not qualify what accounts as visibility - others @patrickhlauke have made the point elsewhere (can't find the issue though) that a single pixel would minimally meet that SC. And by virtue of 1.4.11 that single pixel would need to meet 3:1 and may essentially merge with the control. As stated in #1399 by Alastair
So I think there is a case to replace the proposed text of 2.4.11
with
In all keyboard-only use scenarios, bringing up elements that may hide the focus (which seems to have motivated the change to using "receive" in the SC text of 2.4.11) implies that the user has to move the focus anyway to bring up new content. In the mixed use edge case scenario mentioned by @mbgower of some custom tooltip opening on hover over the keyboard-focused element and potentially thereby hiding it. I think this can be separated as additional intentional user action after the element receives keyboard focus.
|
It could either reduce down to "1" (or a few) pixels, or it could fade visually. I think it would still need to meet contrast with the background to pass 1.4.11, but there might be an argument about that. I don't think I'm setting up a false-dichotomy (choice) by saying we can have either:
The "has" implies a permanence which is not possible if you treat the viewport and other content as affecting your view of the indicator. On the other hand, if you treat the control and it's settings for the focus as what is tested/measure and ignore the scrolling/viewport/non-modals aspects, then the unobscured bullet doesn't make sense. But you can use "has focus". |
about: "When user interface components has keyboard focus..." and remove the unobscured bullet, OR" This is not per se needed as we can mention the 'default' load/state in the wording, like: "Not fully obscured: The item with focus is not entirely hidden by author-created content in the initial / default state" or mention an action done by a user, like: "Not fully obscured: The item with focus is not entirely hidden by author-created content unless obscuring is done by a users action" |
"in the initial / default state" is problematic. Easy to interpret as on page load. "is done by a user's action". What constitutes a user action? Without scoping that down (and making the bullet pretty awkward) this effectively gives a very large hole. |
From today's meeting: We need to refine that last bullet and come back to the group next time (week?) |
This was discussed again: https://www.w3.org/2021/01/19-ag-minutes.html#t04 The survey question was:
Most were in favour of tackling the sticky footer/header issue, so not changing the current text. If someone can come up with text (quite rapidly) that overcomes the dichotomy, we can review that, but it isn't apparent yet. |
The formulation of the SCs for the focus indicator is strongly oriented towards a focus indicator consisting of, for example, a line, a border or a change of foreground and background color. However, there are theoretically and in practice other ways to identify the focused element. The question is whether these are allowed and whether the SCs (for measuring size and contrast) then apply accordingly:
Apart from the fact that all these examples I mentioned are difficult to measure (whether they meet the size and contrast requirements), it can happen, for example, that a small animation, which is hardly noticeable (shift of 1px) meets the size and contrast requirements, a clear animation (shift of 20px) does not meet the requirements, because then the letters theoretically overlap in such a way that the size is not met
The text was updated successfully, but these errors were encountered: