2.4.7/2.4.11/2.4.12 Must a focus indicator always be displayed?

[JAWS-test]

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:

• Fade-in of skip links (which are invisible without focus) - fade-in is usually well visible, but if two consecutive skip links share the same position ("Skip to main content", "Skip to navigation"), the changed text may not be sufficient to meet the minimum size requirement for the focus indicator. Skip-links often do not have their own focus indicator
• Moving or enlarging buttons while receiving focus (this is often seen with social media buttons at the right or left side of the page)
• Micro-animations at the beginning or during the entire focusing process (e.g. vibration, color change, etc.)
• Changing text content

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

[awkawk]

• Fade-in of skip links (which are invisible without focus) - fade-in is usually well visible, but if two consecutive skip links share the same position ("Skip to main content", "Skip to navigation"), the changed text may not be sufficient to meet the minimum size requirement for the focus indicator. Skip-links often do not have their own focus indicator

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.

• Moving or enlarging buttons while receiving focus (this is often seen with social media buttons at the right or left side of the page)

Enlarging is still a change that can be measured. Moving could be as well but we would need to see the implementation.

• Micro-animations at the beginning or during the entire focusing process (e.g. vibration, color change, etc.)

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).

• Changing text content

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.

[detlevhfischer]

Proposed working group answer: Thank you for your comment. The Working Group's understanding regarding the permanence of focus indicator is that it must be displayed as long as the element has focus (source needed).

• In cases of initial animation, the final state after the animation ends would need to be compared to the unfocused state. So the micro-animations that you mention can be discounted.
• Skip links that become visible when focused would meet 2.4.11 if the change of contrast of the minimum focus indication area is 3:1 or better. In cases where one skip link replaces another in the same location, the focus indication area will likely be large enough as different text content will have pixels in different locations (and usually skip link length will differ anyway).
• The moving or enlargement of buttons as well as the changing of text content would typically imply changes that add up to more than the minimum focus indication area, so as long as the displacement stays in place while the element is focused, this would technically meet the SC.

[alastc]

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:

When user interface components receive keyboard focus, all of the following are true

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.

[detlevhfischer]

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

Non-text contrast doesn't specify what the contrast is with, so it allows for low/no-contrast of the focus indicator with the component.

So I think there is a case to replace the proposed text of 2.4.11

When user interface components receive keyboard focus, all of the following are true

with

When user interface components have keyboard focus, all of the following are true

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. This might be captured in a note along the lines of (wording needs improvement):

Note: Exempt from the requirement is the hiding of focus caused by consequent user actions, such as scrolling or the opening of custom tooltips.

[alastc]

I fail to see how 2.4.7 or 1.4.11 would guard against an implementation where the focus fades.

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:

• "When user interface components has keyboard focus..." and remove the unobscured bullet, OR
• "When user interface components receive keyboard focus..." and keep the unobscured bullet

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".

[jake-abma]

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"

[mbgower]

"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.

[alastc]

From today's meeting: We need to refine that last bullet and come back to the group next time (week?)

[alastc]

This was discussed again: https://www.w3.org/2021/01/19-ag-minutes.html#t04

The survey question was:

This conceptually overlaps with the sticky-footer aspects in the last bullet, because the start of the SC was adjusted to "When user interface components receive keyboard focus", so that the unobscured bullet would not be too draconian. (E.g. if the user moves something over the focused element that can't be the author's issue.)

It appears to be the case that the SC can use either:

• "When user interface components has keyboard focus..." and remove the unobscured bullet, OR
• "When user interface components receive keyboard focus..." and keep the unobscured bullet

It seems to be a choice between solving the sticky-footer problem, or the fading focus indicator problem. There are some ideas in the github issue, but nothing stood out as a solution.

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.