Comment from IBM: Reword Focus Appearance (Minimum) to provide clarity

[mbgower]

The current preamble of 2.4.11 reads as follows:

For the keyboard focus indicator of each User Interface Component, all of the following are true:

This wording does not align with the 'consequence' of taking focus, which is particularly inherent in the fourth bullet, which reads:

Unobscured: The item with focus is not entirely hidden by author-created content.

It is possible to misinterpret this bullet that the item with focus must always be visible, even if the user, for instance, scrolls down a page after bringing the component into focus (thus preventing the user from scrolling).

All four bullets are considerations for when an item receives keyboard focus, so we believe the following provides clarity, and makes the fourth bullet more easily understood in conjunction with the other bullets:

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

Note that we have also put "user interface components" in lower case, to match both the definition and other occurrences in WCAG 2.1. Potentially this could also be a link to the definition.

[awkawk]

@mbgower Have you seen my suggestions in #1341? Seems to be some overlap

[mbgower]

@awkawk There is definitely some overlap, and some other things you tackle seem reasonable. However, I also agree with Alastair's comment that changing the 4th bullet to being about the indicator instead of the item with focus is problematic.

[guyhickling]

IBM's and @mbgower's wording is much clearer and much easier for people to read and understand. Always go for clarity, assuming the meaning is unchanged! Even if it takes a few words more. The most usual excuse people offer for making the WCAG so abstruse is to have fewer words. But here the clearer version is also 4 words less........!

[RavenAlly]

Could the "receive keyboard focus" wording be a bit too absolute in terms of timing?

What if my focus style starts out conformant "on receiving focus" (pass!) but transitions to a non-conformant colour / size? Still got focus but no longer meets the spec.

[guyhickling]

@RavenAlly Good point. Perhaps "have keyboard focus" would be better than "receive...."

[mbgower]

Could the "receive keyboard focus" wording be a bit too absolute in terms of timing?
What if my focus style starts out conformant "on receiving focus" (pass!) but transitions to a non-conformant colour / size? Still got focus but no longer meets the spec.

The concern with changing it to "have keyboard focus" is it results in the same issue that existed before this proposed change. Things can happen in an UI which may result in the object with focus no longer being visible (as basic as user moving viewport so it BECOMES obscured by author content).

Trying to make this SC 'bullet proof' against odd or creative poor implementations can lead to some unanticipated repercussions. It's possible someone could decide to take away a clear focus after achieving it. It's also possible that someone could come up with something that meets the SC that would be completely unusable by reversing a patterned border (someone created a demo of that). At some point we need to author the SC against the probable (and common) behaviours. Not uncommon 'what ifs'.
Changing this to measure focus when the item receives focus allows us to analyze its state after undergoing the transition from unfocused to focused.

[alastc]

If PR #1403 is accepted, I think that deals with this issue.

[alastc]

Closing, as #1403 was merged.