Option role: Change aria-selected from required to supported and remove default value

[mcking65]

For issue #700, made the following changes to the option role section in index.html:

1. Remove sentence from description that states there is an default value of false fore aria-selected on option elements.
2. Remove aria-selected from required states and properties row of attributes table.
3. Add aria-selected to supported row of attributes table.
4. Remove default value for aria-selected from implicit values row of attributes table.

Note: This cascades to treeitem so that aria-selected is not required on treeitem.

---

Preview | Diff

[aleventhal]

The way I always understood things were that containers such as listboxes had modes, single selection and multiple selection.
From Core AAM: "In the single selection case, selection follows focus (see the section "Focus States and Events Table" for information about focus events)..."

What this means is that if the author doesn't explicitly put aria-selected="false" on the currently focused item in a single selection container, it will be treated as selected by default. This mimics what you see in native widgets.

[asurkov]

I think implicit value of aria-selected for role="option" makes sense, since it indicates a presence of selectable state on the element; in contrast to to other non-selectable-by-default roles like role="columnheader".

Agreed, implicit aria-selected="false" sounds confusing in conjunction with "selection follows the focus" case, but probably the sentence should be reworded, something like "role option has an implict aria-selected value of 'false', until it is implicitly selected based on focus (link), in which case it defaults to 'true'.

[melanierichards]

+1 to @asurkov's comment:

I think implicit value of aria-selected for role="option" makes sense, since it indicates a presence of selectable state on the element; in contrast to to other non-selectable-by-default roles like role="columnheader".
Agreed, implicit aria-selected="false" sounds confusing in conjunction with "selection follows the focus" case, but probably the sentence should be reworded, something like "role option has an implict aria-selected value of 'false', until it is implicitly selected based on focus (link), in which case it defaults to 'true'.

[jnurthen]

@mcking65 This PR has been around for a while. Are there any of these comments that need actioning?

[JAWS-test]

I argue that aria-selected is mandatory, at least for ARIA roles, which by default are intended to be selected like option and tab (see #1094)

[mcking65]

@melanierichards, @asurkov, @aleventhal, we need to account for the situations where authors are using aria-checked instead of selected. I'm not sure what the best way to do this is. I think we should discuss. There is not time to do so for ARIA 1.2.

We also need to discuss whether ARIA needs to support patterns that allow authors to use both checked and selected.

[melanierichards]

cc @boggydigital

[joanmarie]

@jcsteh: We'd like your opinion on this when you have a moment. Thanks!

[jcsteh]

Oo. Quite a conundrum.

Talking only about selection, I agree with @asurkov's #799 (comment). Saying there's no default value is misleading because in a single select widget, options without aria-selected get exposed as selected. In a multi select widget, options without aria-selected get exposed as not selected. ("Not selected" and "doesn't support selection" are two different things.) Doing otherwise is a backwards compat break. So, we should be clear that the default is different depending on single/multiple selection.

On the other hand, the fact that option/treeitem support aria-checked complicates things. It (probably?) doesn't make sense for something to be both selectable and checkable, since they both presumably convey the same meaning, just with slightly different presentation.

My suggestion:

1. Unless aria-checked is specified, aria-selected should default to true on a single select widget, false on a multi select widget.
2. If aria-checked is specified, aria-selected has no "default". Open mapping question: should platforms which have the selectable state (or equivalent) stop exposing it in this case? I think this is appropriate.

[sinabahram]

Regarding selection and checked not being different. I want to make sure this accounts for the use case where noncontiguous multiple selection is available inside a tree view whose components can also be checked? Imagine making blocks-based programming accessible via a tree view, and noncontiguous selection is available for group deletion, moving, etc., but items can be checked as well, for example, as part of controlling membership in a different set subject to different actions. I could also imagine this use case in certain digital audio workstation type scenarios, or other advanced applications in which more than one parallel track of actions is being controlled.

[MarcoZehe]

On the other hand, the fact that option/treeitem support aria-checked complicates things. It (probably?) doesn't make sense for something to be both selectable and checkable, since they both presumably convey the same meaning, just with slightly different presentation.

I am actually not sure about that. In a single-select tree view, items can be checkable, see certain types of Windows Explorer options or such that have checkable tree items. The Selected state moves along with the focused state, but is definitely there. That item can then be checked or not. Heck, some are even acting like radio buttons, where one of several can be checked at one time.

Where I agree is if a tree has multiple selectable items. Here, I feel like selectable and checkable are going hand in hand, although I currently don't remember ever seeing such a tree view with multiple selection myself. List boxes with option items, yes, and for that, this statement is true I guess as well, e. g. selection and checkmark go together in multi-select scenarios.

[aleventhal]

@jcsteh do you mean the focused option in the single selection case defaults to selected? All of the unfocused options would default to not-selected.

I'm not sure why that rule would need to change due to the presence of checked or not. Honestly, we could probably even get rid of the selection follows focus rule without consequence. I'd be nervous to do so, but the reason it's in there is really historical. We were trying to make listbox/combobox widgets look like they did in MSAA.

[sinabahram]

I think that selection should follow focus by default. To not do so violates a ton of assumptions/expectations.

[mcking65]

Closing; replaced with #1340