Authors do not need to set aria-selected in single-selection containers…

[carmacleod]

…where selection follows focus

This change attempts to address one small aspect of #1052

---

Preview | Diff

[aleventhal]

One case that comes up is a single selection container where the author wants to convey that nothing is selected, not even the focused item. In this case, the browsers that I know of will make use of aria-selected="false" on the focused item, and should result in the screen reader conveying that the item is not selected.

[carmacleod]

Wow, that's a wild case that should be spec'd explicitly, because I wouldn't have guessed that one.

How about:

Authors SHOULD NOT set aria-selected in single-selection containers where selection follows focus unless aria-selected=false is being used on the focused item to indicate that the container does not currently have a selection.

Would that work?

[jnurthen]

I understand the intent but as far as I know there is no negative consequence to an author setting aria-selected on the focused node - they are just doing extra unnecessary work. Why would we make this a SHOULD NOT?

[carmacleod]

The intent is to clarify. SHOULD NOT makes it very clear, but I'm happy to make it a "don't need to", if that's preferred. Including the preceding paragraph for context, that would look something like:

This attribute is used with single-selection and multiple-selection widgets:

• Single-selection containers where the currently focused item is not selected. The selection normally follows the focus, and is managed by the user agent.
• Multiple-selection containers. Authors SHOULD ensure that any selectable descendant of a container in which the aria-multiselectable attribute is true specifies a value of either true or false for the aria-selected attribute.

Authors do not need to set aria-selected in single-selection containers where selection follows focus, unless aria-selected=false is being used on the focused item to indicate that the container does not currently have a selection.

[jnurthen]

I like this better. I want to avoid checkers thinking this is telling them to flag an error for something like this.

[smhigley]

I'm pretty confused by this, actually. Shouldn't aria-selected always be used to indicate selection, regardless of whether that selection follows focus or not? Perhaps we could specify that UAs should default the currently focused option to selected unless aria-selected is explicitly false, but that seems like a note for UAs and not for authors.

For authors, it seems to me that the safest, most readable, and most cross-UA-friendly way to handle aria-selected is to always set it to true or false on custom options. Why would we encourage them to do otherwise?

[JAWS-test]

I do not think this is a good idea. As soon as a single selection element has the focus, AT will know which item was selected even without aria-selected. But what if I read with the virtual cursor of the screen reader or open the element overview and the element does not have the focus. Even then I want to perceive the selected item correctly and this is only possible with aria-selected. Therefore I would say that aria-selected must always be present

[carmacleod]

Ok, I'm convinced that this new sentence could do more harm than good.
I would like to point out though that it is just stating explicitly something that was implicit already in the spec for aria-selected, which says that:

This attribute is used with single-selection and multiple-selection widgets:

• Single-selection containers where the currently focused item is not selected. The selection normally follows the focus, and is managed by the user agent.
• Multiple-selection containers. Authors SHOULD ensure that any selectable descendant of a container in which the aria-multiselectable attribute is true specifies a value of either true or false for the aria-selected attribute.

It doesn't actually say that it is used in single-selection widgets where selection follows focus. In fact, the line about "The selection normally follows the focus, and is managed by the user agent." seems to imply otherwise. This is reinforced by the next paragraph, which confusingly says:

If no DOM element in the widget is explicitly marked as selected, assistive technologies MAY convey implicit selection which follows the keyboard focus of the managed focus widget. If any DOM element in the widget is explicitly marked as selected, the user agent MUST NOT convey implicit selection for the widget.

So how can we make this clearer (and more robust)? Do we want to say something along the lines of the UA (and AT?) behavior being "fallback" behavior for when the author doesn't set aria-selected? Also, why would assistive technologies convey implicit selection if the user agent was already doing it? There's something very unclear in here, and I'd like to clean it up somehow.

[JAWS-test]

Hi @carmacleod
I know that this is what the specification says so far. I just wonder if this should not be changed in the direction that aria-selected is always necessary as soon as a selection has been made, so that the selection can be perceived with AT even in unfocused state (as it works with standard HTML elements)

[mcking65]

I think the language needs to be updated to specifically address widgets where selection does not follow focus. I am specifically concerned about a tree where not all items are selectable and selection does not follow focus. In such a tree, aria-selected is required on all selectable elements. If none are marked with aria-selected=true and focus is on an item that is not selectable, the current spec language could be read as saying it is OK for the user agent to convey implicit selection for that item. Note that treeitem does not have a default value for aria-selected, so by default a treeitem is not selectable. By comparison, all options are selectable.

What I don't understand is how the user agent or assistive tech are supposed to know if selection follows focus or not. The only widgets where it seems like that might be feasible are listbox and tablist. But, that rules out the possibility of a single select where nothing is selected.

It might the be the case that the only way to make this unambiguous is to ensure that an item is only considered selected if it has aria-selected set to true. As soon as we allow for the possibility that focus implies selection, problems arise.

One other issue: If we tell authors they do not have to set aria-selected to true in a single select where selection follows focus, how does an AT know which item is selected if the widget does not contain focus?

[JAWS-test]

@mcking65

The only widgets where it seems like that might be feasible are listbox and tablist.

Also in a tablist, focusing is not identical to aria-selected, see https://www.w3.org/TR/wai-aria-practices-1.2/examples/tabs/tabs-2/tabs.html

And for all elements (including listbox and tablist) the selected item should be perceptible even without focusing. I already mentioned this in the comment above (and in #1094) and you also mentioned this in the next paragraph. Therefore I think that aria-selected should always be used

[mcking65]

I think #799 should be decided before considering this PR; #799 has important ramifications.

However, the more I consider this PR, it seems deeply problematic that the user agent could "automatically" change selection. If focus and selection are one in the same, then there is no need for selection. So, just communicate focus and let selection remain undefined. If selection has meaning, require the author to specify it. The browser should not be guessing about selection and then changing the widget for the author.

Even if we tell authors they do not need to set aria-selected when they intend selection to follow focus, then user agents would have to modify the web page or the selected state will be lost on blur. I think that is inconsistent with ARIA's contract with authors and user agents.

If the user agent were going to change selection automatically, We would also need to be specific about what is meant by focus -- don't forget about aria-activedescendant.

BTW, I also just noticed that aria-multiselectable does not have an undefined value. That means that by default, the following widgets are assumed to contain selectable items:

• grid
• listbox
• tablist
• tree
• treegrid

In other words, unless we give aria-multiselectable a default value of undefined, these are all single-selects by default. Grid, tree, and treegrid support non-selectable items. Browsers can't assume that selection follows focus in these single-selects because it can't assume the items are selectable. So, at a minimum, this PR needs to be explicit that this special condition of not having to specify selection only applies to option and tab. Of course, if we merge #799, it might only apply to tab.

[carmacleod]

This PR has been superseded by the work going on in #1340
Closing.