Update focus-appearance-minimum.html

[mbgower]

An attempt to address the concerns expressed for the later comments in #2237.
The closing paragraph has become a final exception bullet. A note has been added providing an example as well as information on selection versus focused.
UPDATE: After discussion, returned final point to a paragraph again.

[bruce-usab]

I am fine with this, but please note that this version takes away the page author/owner choice.

these requirements are applied to the sub-component instead.

I had expected to find are allowed or similar.

[mbgower]

Thanks, @bruce-usab . We can certainly swap 'are' with 'may be applied' language as a fallback, but my sense is that with the revision and the State note, we may be able to get away with something a bit emphatic. I've added Wilco and Alastair as reviewers, to get their perspective, since they have been heavily involved in discussion.
Preview

[bruce-usab]

Also, my apologies but I will be joining the call tomorrow (5/3) quite late and probably will miss the substantive live discussion on this item. I am however, content with where the group consensus lands. My concerns have been heard, and I appreciate @mbgower and everyone's considered interaction.

[mbgower]

Note some other tweaking options include:

option 1, remove the if and make it an "and"

• Where a user interface component has active sub-components and a sub-component receives its own focus indicator, these requirements are applied to the sub-component instead.

option 2, same as option 1, but add in "may"

• Where a user interface component has active sub-components and a sub-component receives its own focus indicator, these requirements may be applied to the sub-component instead.

[alastc]

Where a user interface component has active sub-components and a sub-component receives its own focus indicator, these requirements are applied to the sub-component instead.

I think with the associated note (outlining 'selection') we can be emphatic about that, so it is an either/both scenario.

I just wonder about the "and a sub-component" in a complex widget that might have different types of sub-component (e.g. calendar widget with days selected + focused + month buttons).

How about:
"Where a user interface component has active sub-components which receives their own focus indicator, these requirements are applied to the sub-component instead."

[mbgower]

Having gone through a bunch more examples, I think we may have to stick with the "may" language. Here is the challenge: I don't think we want to fail more discrete but clear selection indicators by judging them as focus indicators, and it is possible that someone can do that in many of these cases. For example, think of many tablists where the tab selection is just a thickish underline of the selected tab, or some other form of 'okay' selection indication...




I'm not a huge fan of some of those examples (borderline text contrast issues, etc), but things similar that can pass all other wcag criteria are very common in the wild and there is one thing making them arguably 'not that bad' for interaction, which is proximity.
If you imagine putting a focus rectangle around the whole of each of these interactions, and having them employed as a synchronized tab, I think you can make a case that the group focus indicator is sufficient to orient the user within what is a contained space. It's a lot easier to locate the subtle selection state within a focused component with subcomponents than it is to find a focus indicator anywhere on the page.
I don't want to overplay this proximity consideration, but to me it is a factor in this discussion. Selection simply doesn't need to be as obvious as focus.
But it's entirely possible for someone to interpret the selection indicator as a focus indicator (rightly or wrongly). If we have "may" language, then it prevents a selection state that is usable from failing a misinterpretation of whether a subcomponent focus indicator exists or if it is simply selection is being shown.

On the other hand, I want to make sure that where there is a crappy focus indicator on a subcomponent that needs it (an unsynchronized tablist, a date picker, a multi-select dropdown), that should fail.

So I'm a little torn. Ultimately, the takeaway for me is that the "may" language will get us to a better place -- if there is no group focus indicator, they're going to need one around the subcomponents -- while still providing a fail-safe against people starting to confuse selection with focus (and thus beginning to apply overly vigorous requirements to the selection state).

[alastc]

Ok, well, it was you suggesting it so if you withdraw the suggestion, we can carry on. Presumably with "these requirements may be applied to the sub-component instead"

[mbgower]

@bruce-usab in discussions on the Friday call, it was felt that the sub-component information is not really an exception, and fits better in its former location. Can you abide it there with the updated language?
I have moved out the examples to a note, as you suggest and done minor tweaking on wording.
Please have a look at the latest diff to see how it's ended up.
If this is acceptable, I will create a separate PR for the SC itself to align it (this is just the Understanding document)

[bruce-usab]

Thanks for the ping. I think this is fine.

I agree that the concluding paragraph is not really an exception, and having it in parallel with the actual exceptions is awkward.

[mbgower]

I think this is fine.

Thanks, Bruce.

@alastc I suspect we may run into some synch issues on this. This PR includes the very small change to the normative text (removing sub-component example), but overall it covers the modifications to the note and some changes to the Understanding document.

I don't seem to have a way of deleting this comment, or I would :)

[alastc]

@mbgower can I merge this into the focus-appearance-tweaks branch and put that into a survey?

[alastc]

Saw the email, so I've merged this.