Does 2.4.11 apply to active descendants of a combobox?

[WilcoFiers]

When you expand a combobox or select, users can choose an option using arrow keys. In ARIA this is called the active descendant. So in addition to having a focused combobox, there is an active option. Question is, does 2.4.11 apply to active descendants in addition to the focused control? If so, does the focused control need to have the focus indicator while there is an active descendant?

More generally, I think an intuitive understanding of what is focused can occasionally contradict the programmatically determined focus state. It seems ambiguous to me which one of those to use when the two contradicts, such as in the case of active descendants.

https://www.w3.org/TR/wai-aria-practices-1.1/examples/combobox/aria1.1pattern/listbox-combo.html

[patrickhlauke]

More generally, I think an intuitive understanding of what is focused can occasionally contradict the programmatically determined focus state. It seems ambiguous to me which one of those to use when the two contradicts, such as in the case of active descendants.

this situation (that "focused" doesn't necessarily mean "the element that represents document.activeElement) has been touched on quite a few times before yes. most recently in that lengthy back-and-forth issue #2226, some mention of this as it relates to 2.4.7 here in #1001, but I'm fairly sure there were even earlier discussions)

i think long story short is that SCs mean "focus" in the more general "logical" sense, whatever the user perceives/understands as having focus. not necessarily the programmatic element that the browser thinks has focus (which yes, will make automated testing "interesting", as there may even be fully custom implementations of things - think <canvas> where the entire idea of a focus is "virtual" and handled completely by the author - that simply won't be auto-testable)

[patrickhlauke]

but more specifically to your point about activedescendant ... this is a very interesting case where focus, even logically, is "in two places at once" effectively (even more so for comboboxes that aren't just like selects, but allow freeform typing in the text edit as well as providing a list of options/suggestions). agree that at the very least the understanding doc should devote some explanation to these "special" situations.

[WilcoFiers]

I think we're sort of trying to have it both ways here Patrick. That seems a little off to me. On the one hand I've been hearing that focus is a state, so 1.4.11 can be applied to focus, and that it'd need to be programmatic (4.1.2). But then I'm also hearing people argue that focus should be seen as something independent so that we can apply 2.4.11 to active descendants.

I think it might make more sense for focus to be a programmatic state, and adjust the new SC so that it also applies to active descendants in some way.

[patrickhlauke]

I think we're sort of trying to have it both ways here Patrick

are we? where? (i admit i've lost track of where the very latest thinking/wording on 2.4.11 is)

I think it might make more sense for focus to be a programmatic state, and adjust the new SC so that it also applies to active descendants in some way.

and from an automated testing perspective, that would certainly make sense. but it may well come at the expense of being logical / relating to a user's actual experience / applying to various other situations (like the <canvas> example for instance)

[WilcoFiers]

Well, the way I understand this:

1. AGWG has been saying 1.4.11 requires focus to have 3:1 contrast with its surroundings. It justifies this by saying focus is a state of the component.

2. SC 4.1.2 requires state to be programmatically determined. Since we're saying that focus is state, it follows that focus must be programmatically determined.

3. Under 2.4.11 I think it then follows that, unless there is a violation of 4.1.2, the only thing that needs a focus indicator is a component that has programmatic focus.

The way I see this either focus is a state, and it therefor must be programmatic, or it isn't and therefor 1.4.11 doesn't apply to it.

[patrickhlauke]

1.4.11 and 2.4.11 deal with something visual, so there when talking about "focus" is refers to what a sighted user would assume is the control (which does not necessarily match whatever happens under the hood / programmatically)
4.1.2 deals with programmatic properties of elements/components. which usually does, but doesn't necessarily always, match what visually/logically has focus (again, imagine something like a <canvas> that then draws its own interface - this would be the extreme example of where the visual "focus" can and will be different from the programmatic "focus").

if there's a reasonable way to disumbiguate this in understanding (in a similar way to that discussion ages ago the "when we say 'label' we don't necessarily mean <label> elements, we're talking about the concept..."), sure let's go for that. but i'd strongly disagree with a mechanistic "clearly we're only thinking about programmatic focus in all cases (so that, coincidentally, we can nicely write automated tests for those)

[bruce-usab]

...It [AGWG] justifies this by saying focus is a state of the component.

@WilcoFiers can you point me to where you make this inference? I believe I have been following most of the conversations around state and I do agree with the above statement, since it lacks some nuance. The 1.4.11 UIC mention of states applies to various kinds of state, but that does not imply that focus state is to be added to a UIC that does not natively have that condition as a possibility.

The way I see this either focus is a state, and it therefor must be programmatic, or it isn't and therefor 1.4.11 doesn't apply to it.

I feel like this is a bit reversed. If focus is a (possible) programmatic state, then both 4.1.2 and 1.4.11 apply. If focus is not a programmatic state (or not possible for a particular UIC), 4.1.2 and 1.4.11 might have other implications for the UIC.

[JAWS-test]

Agree with @patrickhlauke that the Understanding documents of 2.4.7, 1.4.11, 2.4.11 and 2.4.12 should indicate that for certain elements the focus visibility refers to the active entry (option, gridcell, treeitem, menuitem etc.). In my opinion, the question is open whether always the whole element (listbox, combobox, grid, tree, menu etc.) needs a focus indicator. If not, it should be noted that often the selected item is identical to the focused item (e.g. single select listbox).
Now, if the parent element does not have a focus indicator, the selected item must have sufficient contrast to the unselected items (whether focused or not) and at the same time the selected item in the focused state must differ with at least 3:1 contrast from the selected item in the non-focused state. Of course, this only applies to elements that are permanently open (listbox, grid, treegrid) and not to elements that are opened or closed like a combobox or submenu.

[stevefaulkner]

Some observations that may be helpful: based on Example 1: List Autocomplete with Manual Selection

tested using

• Microsoft Edge Version 98.0.1108.56 (Official build) (64-bit)
• Inspect Object (64-bit UNICODE Release)

when the edit box has keyboard focus

UIA states for edit are

IsKeyboardFocusable:	true
HasKeyboardFocus:	true

when an option has keyboard focus (navigated to using arrow keys):

UIA states for option are

IsKeyboardFocusable:	true
HasKeyboardFocus:	true

UIA states for edit are

IsKeyboardFocusable:	true
HasKeyboardFocus:	false

[JAWS-test]

The special characteristic of comboboxes is that the focus can actually be in two places at the same time:

• on the list entry that is reached with the arrow keys.
• in the input field, where text can be entered even when navigating through the list.

In the example examined by @stevefaulkner, the focus is always in the input field from the browser's point of view. Only aria-activedescendant causes a different information to be transmitted to the Accessibility API.

[alastc]

I see this as related to my question about what is a "user interface control" (UIC) really? That would define the size.

Previously we have tried to define focus:
https://www.w3.org/TR/WCAG22/#dfn-focus

So from that definition (if we end up using it) then I'd say yes active descendants are covered. And, from a user point of view, that would be the logical approach.

Reviewing previous uses of UIC, I don't think it has mattered that much for previous SCs. For example, for a UIC to be keyboard accessible it doesn't matter whether you consider active descendants as separate or not, it works in either interpretation.

However, when we are calculating size that becomes an issue!

I don't think we should assume people know/understand that there can be two forms of focus for some components.
Given that the visual keyboard indicator (in a good case) will follow the active descendant, we should consider those the UIC / item in scope.

[alastc]

The normative text now includes:
"Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), if the focus indicator is applied to the sub-component then these requirements can be applied to the sub-components instead."

So it allows for either the parent UIC and/or the child components.

There is a new section of the understanding document which addresses this and tries to differentiate focus from selection.

Assuming the change passes next week, I'll close this issue.

[bruce-usab]

I agree with the intent. I like the suggested change. I am not clear where the option is being slotted in.
@alastc by "normative text" is that the SC, a note, or something else?

then these requirements can be applied to the sub-components instead

If that is in Understanding, everything is well and good. It will be problematic for can be to be part of an SC. That is the sort of author choice called out by one of the following is true or (more since 2.1) as an exception.

Another phrasing approach which might work is permitted or allowable. I understand the intent is to give the author a choice for passing the SC, and not to give an auditor an excuse for failing the SC. E.g.:

...if the focus indicator is applied to the sub-component then it is permissible to apply these requirements to the sub-component as a way to meet this success criterion.

Current:

Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), if the focus indicator is applied to the sub-component then these requirements can be applied to the sub-components instead.

Another suggestion:

Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), it is a best practice for the focus indicator to move to the sub-component. For this situation, the requirements should be applied to the sub-components instead.

The above only works if this Understanding. It is too loose for the SC.

[mbgower]

@bruce-usab this is actually part of the normative text (and was reviewed on last week's call).

On Friday's wcag 2.x backlog call, I led us through an exercise in how we need to let it be "can" because it is entirely possible to have the focus indicator only around the whole and have clear focus appearance. Here's an example of a radio button group where this is the case. If you compare to a typical radio button group, you'll notice that there is a focus indicator around the selection state as well. That is arguably a clearer interaction, but I hope you'll agree that in the example provided, the interaction is clear. Where the selection state is essentially providing a point of interaction but cannot be considered the focus. In such a case, the selection state still needs to meet 3:1 through Non-Text Contrast.
I will be expanding on this difference in the Understanding document. Here is a slider example of the same kind of situation where requiring the subcomponent to have focus could lead to problems.

I will be adding more context in the Understanding document on this.

[bruce-usab]

I absolutely agree with can be in principle — but I am pointing out that we have taken great care with 2.x SC to avoid may/might/should/could and can be. It introduces ambiguity in the SC which is not able to be addressed in Understaning.

@mbgower – please try crafting a version that makes it unambiguous that the can be choice/clause is sufficient for meeting requirement. With the current phrasing, an unfriendly (and less informed) 3rd party auditor is provided space to fail an accessible (and preferable) implementation. I think it needs to explicit that applying the requirements to the subcomponent is sufficient for meeting the SC (and that the current phrasing with can be is not quite clear enough on this point).

Something we have also done with some 2.1/2.2 SC is have an exception following the SC. For this SC, that approach might allow the main body of the SC to simpler (since it would not have to mention subcomponents at all). With this approach, at the end of the SC, we might have an exception similar to the following:

Exception: Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), if the focus indicator is applied to the sub-component then it is permissible (and be preferable) for these requirements to be applied to the sub-components instead of the parent component.

[mbgower]

@bruce-usab From my review, I don't think we can comprehensively say it is 'best practice' or even 'preferred' to have focus go to the sub-component.

Here are some concrete examples to further illustrate that:

Select

A select element by default allows a single item to be selected. It must have an unfocused state. Here is a default one in Chrome that is open by default showing 4 models of car, before it receives focus (and I'm ignoring the failure of the selection emphasis here as a user agent default)

A focus indicator has to occur on the unopened (or pre-opened) select component itself, but there is never any need for a focus indicator to exist on an open select's subcomponents because the selection state alone (assuming it meets 3:1) is entirely adequate. Here, Chrome adds a blue focus indicator around the whole, and also makes the unfocused gray selection state of the item called "Saab" become blue (ignoring that Chrome's default contrast for selection has not improved).

In some circumstances, adding the focus could potentially make the experience visually 'noisier.'

However, a multi-select MUST have a separate focus indicator to allow someone to differentiate between a selected item and the item that has focus. Here are two views of that, one showing the focus on "Fiat" while "Saab" is selected; the other showing both focus and selection on the "Saab" item as I traverse through it. In both instances, the same dark blue indicator that surrounds the whole select element is also used on the item with focus. It meets 3:1 contrast against both the selected and unselected items.

Radio (and other) groups

As mentioned above, a radio group that has a focus indicator has no need for a focus indicator on individual buttons. Most browsers add a redundant focus indicator around the radio button as well. But only one radio button can ever be selected, so if there is a group focus around the whole it is entirely adequate.

Some grouped components (such as tablists) can actually greatly benefit from a group focus, which clarifies the keyboard interaction for sighted keyboard users. Where the tabpanel is synchronized with the tabitem selected, no focus indicator is necessary on the tab item so long as the tablist has a group focus indicator. (An unsynchronized tablist needs a focus state for the same reason a multiselect select element does.) I've documented this in the understanding document (with images)

Star rating

As demonstrated in the star-selection in my prior comment, trying to put a focus indicator around the subcomponent in a star rating system that allows half stars to be chosen could create an extremely odd design interaction. Where there is a group focus indicator, it is clear when you are and are not interacting with the start rating. Here is a 5-star rating system, currently with 2.5 stars selected, with and without a dark blue focus indicator around the whole.


If you are telling people it is preferred to have a sub-component focus indicator, when no star is selected, where would the focus indicator go? Since both half and whole stars can be selected, does the focus indicator only go around the second half of it? How about when a whole star is selected?

In summary, a component is always going to need a focus indicator with our current language, and in many circumstances, the focus going to the sub-component is going to make sense. But there are so many possible design options, that I do not think we can say it is best practice or preferred that the subcomponent should take the focus indicator. I think the "can...instead" wording we have creates enough accommodation for this.

[bruce-usab]

I am (also) happy for us not to say preferred or best practice.

My only concern is that this will be the first may/might that is in the normative body prose of an SC.

[mbgower]

There is no "may" or "might" language. There is "can" and "instead".

We do use both "at least" and "can" in 1.1.1

then text alternatives at least provide descriptive identification
then it is implemented in a way that it can be ignored by assistive technology.

Many SCs use "can" either in the preamble or the exceptions. I count over a dozen occurrences, often but not only in this form:

Information, structure, and relationships conveyed through presentation can be programmatically determined

I find Keyboard Trap is on similar 'loose' ground to what we're doing:

If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

I think I understand the concern that "can" in most of these circumstances probably should have been "must".

[bruce-usab]

In 1.1.1 and 1.3.1. use of can be is an imperative. In 1.1.1 and 1.3.1 can be easily could have been replaced by is or are.

In 2.1.2 Keyboard Trap can be is setting up the condition. Instead of If ... can be we might have written When ... is.

I realize the current prose is not literally using may or might. But with the current phrasing of this SC, can be is a synonym for may or might. Please fix this.

[mbgower]

There is the possibility of making the entire final paragraph another exception bullet....

@bruce-usab it seems like you may have been suggesting that. If such was done, would the current wording be acceptable?

We'd have to think that through carefully.

[mbgower]

i.e.:

• Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), if the focus indicator is applied to the sub-component then these requirements may be applied to the sub-components instead.

[bruce-usab]

@mbgower – I don't have clarity as to where the the current complete wording of the SC may be found. Please provide. I would be pleased to take a pass at formatting the option as an exception. I will not include preferred or best practice. Is it okay for me to reply back to this thread? Would a pull request be better?

[mbgower]

@bruce-usab I think this is most current with my PR:
https://raw.githack.com/w3c/wcag/1102e97aa9e4bdab1d7b8462c3fafea8a9f232f2/understanding/22/focus-appearance-minimum.html

[bruce-usab]

Okay, I think the fix is easy then. Just change the concluding paragraph to another exception bullet (and avoid can be).

Current P tag:

Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), if the focus indicator is applied to the sub-component then these requirements can be applied to the sub-components instead.

Proposed LI tag:

• Where a user interface component has active sub-components to which a focus indicator is applied, then it is permissible tor these requirements to be applied to the sub-components instead of the parent component.

Also I would recommend moving the example (for example, an opened drop-down menu shows a list of menu items) into the note.

[mbgower]

@bruce-usab I've made a new PR that attempts all those things. I believe with the rewording and the added information in the note on selection, that we may be able to more emphatically say that where sub-components have a focus indicator, it must meet these requirements.
@WilcoFiers and @alastc please review against any examples you can find, and suggest tweaks.
#2345

[bruce-usab]

Rewording does not seem to provide page author/owner a choice. I commented in PR.

[mbgower]

@WilcoFiers I believe the changes to the normative text have addressed your question. If you concur, please close. If not, please update the ticket.

[alastc]

The updates, particularly this addition to the normative text address this issue:

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