[Combobox] Align the aria-selected behaviour in examples

[silviuaavram]

Hello! I am opening this issue to ask about aligning the aria-selected attribute value throughout the Combobox examples.

To start with the spec:

For a combobox that controls a listbox, grid, or tree popup, when a suggested value is visually indicated as the currently selected value, the option, gridcell, row, or treeitem containing that value has [aria-selected](https://w3c.github.io/aria/#aria-selected) set to true.

There is a distinction between a selected item and a visually highlighted item (by mouse or keyboard), and, from my understanding, aria-activedescendant on the combobox is enough for screen readers to tell the user which item is highlighted. Consequently, we should use aria-selected on the item that is selected, right? By enter / space bar (select only) or if the combobox has automatic selection on keyboard navigation.

Providing my assumption above is correct, https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/#combobox is correct. It only adds aria-selected as true on the selected item. https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/grid-combo/ also has this behaviour.

https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-autocomplete-list/ adds aria-selected on the highlighted item, however. Should we also correct this example to follow the behaviour I assume is correct?

At the same time, in the attribute table below the example, aria-selected has the following description:

Specified on an option in the listbox when it is visually highlighted as selected.
Occurs only when an option in the list is referenced by aria-activedescendant.

Which does not align with the selected-only and grid-combo examples, but aligns with the autocomplete-list one.

Long story short, can we align this information for all the examples? And by this I mean correct the actual example implementation and also the attribute description in the table, if needed?

From downshift's point of view, I would like to actually implement the solution with aria-selected for selected items, and let activedescendant only for the highlighting part. Before moving ahead with this, I wanted to make sure I am going to implement the correct behaviour, as we mean to follow ARIA 1.2 specs. Right now we have aria-selected as true for highlighted items in useCombobox, and I'm ready to change that behaviour in the hook.

downshift-js/downshift#935

Also, I am open to contribute to the examples page, after we agree on the implementation. Thanks!

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Combobox select vs focus issues.

The full IRC log of that discussion

<jugglinmike> Topic: Combobox select vs focus issues
<jugglinmike> github: https://github.com//issues/2962
<jugglinmike> Matt_King: I did further exploration here, and essentially, our documentation about aria-activedescendents is not in-line with aria-selected
<jugglinmike> Matt_King: This issue could be broken out into multiple issues, but I think the thing we need to talk about right now is... comparing two examples: "select-only combobox" and "combobox with list-autocomplete"
<Matt_King> combobox with autocomplete list: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-autocomplete-list/
<jugglinmike> Matt_King: If we compare these two, there are some differences that I'm not sure we want to have
<jugglinmike> Matt_King: for the editable combobox with list-autocomplete--the behavior if you go into the combobox, you find a list of territories. If you don't type and you just "down arrow", it opens the combobox, and you can go through all the states
<jugglinmike> Matt_King: ...in this case, were you just down-arrow, I don't believe aria-selected is changing as you move through the list. It only changes when you press "enter"
<jugglinmike> Matt_King: The feedback in this issue is that we ARE setting aria-selected but that we shouldn't be
<jugglinmike> Matt_King: The real question here is: should pressing an arrow when visual focus is in the list box change the value of aria-selected in the combobox with list-autocomplete?
<jugglinmike> Matt_King: Right now, it appears to be doing that. The feedback in this issue (if I'm reading it correctly) is that it should not.
<jugglinmike> CurtBellew: If I arrow through, I don't see the value changing. If I hit "tab", whatever I am "on" becomes the selection
<jugglinmike> Matt_King: Right, that's true in both examples we're considering
<jugglinmike> CurtBellew: For me, that makes it seem like it's selected. But I know I can hit the "escape" key to close it, and when I do, nothing is selected
<jugglinmike> Matt_King: We had a discussion about that behavior in particular. In the documentation of keyboard support for select-only combobox... It seems that "tab" is not listed. That seems like an oversight to me
<jugglinmike> Matt_King: I think it's an oversight because I know the current behavior for "tab" (that is: to "select and close") was an intentional behavior
<jugglinmike> Matt_King: Oh, pardon me. "tab" is documented
<jugglinmike> Matt_King: Never mind what I was saying about the oversight just now
<jugglinmike> Matt_King: It's an intentional behavior. It's documented in the select-only combobox, but it's not documented in the combobox with list-autocomplete
<jugglinmike> Matt_King: The person who raised this issue is perferring the behavior of the select-only combobox
<jugglinmike> Matt_King: They want to make the combobox in their component library work that way
<jugglinmike> Matt_King: At a minimum, they're saying that our documentation is inconsistent, and I 100% agree with that
<jugglinmike> Matt_King: I'm just not sure which behavior we want
<jugglinmike> CurtBellew: In select-only combobox, there is a visual checkmark to indicate selection state. That's not present in combobox with list-autocomplete
<jugglinmike> Matt_King: I think the primary question here is around aria-selected.
<jugglinmike> Matt_King: There's some strangeness in the list-autocomplete example. I observed it earlier, but I'm having trouble recalling it, now
<jugglinmike> CurtBellew: What is the benefit of changing aria-selected as I arrow through the list? Does it create problem to NOT set aria-selected as I arrow through?
<jugglinmike> Matt_King: I'm not sure, now that I think about it. It's like you almost don't need aria-selected at all
<jugglinmike> CurtBellew: On "select-only", you visually see what's selected. I think the aria-selected behavior makes sense there because it matches the visual experience
<jugglinmike> Matt_King: I think there's room for some asynchronous discussion here
<jugglinmike> Matt_King: We've at least recognized that there are inconsistencies. We should identify them formally and decide what to do from there.
<jugglinmike> Zakim, end the meeting

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Combobox select vs focus issues.

The full IRC log of that discussion

<jugglinmike> Topic: Combobox select vs focus issues
<jugglinmike> github: https://github.com//issues/2962
<jugglinmike> Matt_King: We discussed this at the end of last week's meeting.
<jugglinmike> Matt_King: It didn't feel like we got to a place where we made decisions
<jugglinmike> Matt_King: It still seems like there's room for asynchronous discussion. I'm just not sure that we have a clear definition of the problem.
<Jem> https://github.com//issues/2962#issuecomment-2007922864
<jugglinmike> jongund: We were concerned about being consistent with standard select boxes
<jugglinmike> Matt_King: Basically, it does seem like a key question is whether or not selection should follow focus in the list box
<jugglinmike> Matt_King: In the select-only combobox, the selection does not follow the focus. In the list with auto-complete, the selection DOES follow the focus
<jugglinmike> Matt_King: That's the primary difference between the two. Is there a strong, good rationale for that?
<jugglinmike> Matt_King: I can explain the rationale for selection not following focus in the select-only combobox, and I think it is explained in the pattern
<jugglinmike> jongund: If you are going through using the up and down arrows to use the list, but if you hit the "tab" key, that's where the difference shows up
<jugglinmike> Matt_King: Reviewing the select-only combobox again, under "keyboard support", we have "listbox popop", and it says "tab sets the value to the focused option (it doesn't say 'selected' option) and then closes the combobox and performs the default action"
<jugglinmike> Matt_King: We have that behavior even though selection doesn't follow focus
<jugglinmike> Matt_King: For "down arrow", it just says it moves visual focus
<jugglinmike> Matt_King: This probably should say that "When it's visually indicated as selected (i.e. with a checkmark) [...]"
<jugglinmike> Matt_King: Oh, there is a copy-paste error here. It says, "only when an option is referenced by aria-activedescendent [...]" but that is not true. That part of this is truly a bug
<jugglinmike> Matt_King: That's a very fast-fix bug, it's editorial, and it's important.
<jugglinmike> Matt_King: I think that the past discussions, we had a lot of people (including Sarah and James) agreeing that tabbing out should set a value
<jugglinmike> Matt_King: Just like what it says here in the documentation of "tab" in the example.
<jugglinmike> Matt_King: ...in the table "listbox popup keyboard support"
<jugglinmike> Matt_King: I know we had strong alignment on that behavior
<jugglinmike> Matt_King: I think the person who wrote this issue is actually asking for that to be the behavior for the editable combobo with autocomplete
<jugglinmike> Matt_King: If we were to change the list-autocomplete combobox to use "Selected" the way that select-only combobox does, I wonder what the ramifications would be
<jugglinmike> Matt_King: In the editable combobox with list autocomplete. The only way that you can get to every state with the arrow keys is if the edit box is empty
<jugglinmike> Matt_King: If the edit box has a value, then you can't
<jugglinmike> Matt_King: If I type "a" and choose the first one ("Alabama"), now, there's no way to open the list box and see all 50 states as long as "Alabama" is in the list box
<jugglinmike> Matt_King: That's a fundamental difference
<jugglinmike> Matt_King: jongund do you think there should be a command (say, "Alt + Down arrow") that allows you to open the listbox with everything present?
<jugglinmike> Matt_King: If it didn't filter, though, then that would break people's expectations
<jugglinmike> Matt_King: aria-selected doesn't seem to play a role in this. If you don't have a selected value, then selection just follows focus
<jugglinmike> jugglinmike: Maybe we should make the filtering dependent on whether a selection event occurred.
<jugglinmike> jongund: If aria-selected is following focus, then it doesn't really provide you with any additional information in this example
<jugglinmike> Matt_King: Yes. I think what jugglinmike and Jem are saying is that you would not filter the list if a selection event occurred and a value had been selected
<jugglinmike> Jem: Yes
<jugglinmike> jugglinmike: Yes
<jugglinmike> Matt_King: if you were to tab into this and "Alabama" was already there, and you pressed "down arrow", you would get all the options and see "checked" next to Alabama
<jugglinmike> Matt_King: And I suppose that if you do type a character, then the whole value should be selected automatically so that your key presses are replacing the selected value
<jugglinmike> Matt_King: Is this realistically the behavior that people want? If there is a selected value in the box, then should the value still serve as a filter?
<jugglinmike> jongund: It seems to me that aria-selected should correspond to some visual indication of a selection. Since in this case, there is no such visual indication, there doesn't seem to be an appropriate use for aria-selected
<jugglinmike> Matt_King: That's a good point
<jugglinmike> Matt_King: In the "combobox" section of the ARIA spec, there's nothing in the prose about aria-selected
<jugglinmike> Matt_King: So what jongund is suggesting would be in-line with the spec
<jugglinmike> Matt_King: Under "listbox", there's nothing in the prose about it
<jugglinmike> Matt_King: but it's under "inherited states and properties"
<jugglinmike> jongund: It looks like the "option" role REQUIRES aria-selected
<jugglinmike> Matt_King: In the latest version, aria-selected isn't required, it says it's "supported"
<jugglinmike> Matt_King: We changed this. In the current editor's draft, it's "supported" and not "required". It does not have an implicit value
<jugglinmike> Matt_King: This is a little tricky, but it's not meant to be!
<jugglinmike> Matt_King: What jongund suggested (removing aria-selected completely), I think it would be in-line with the other example, as well.
<jugglinmike> Matt_King: This meeting has turned into a deep-dive into the combobox, hasn't it?
<jugglinmike> Matt_King: It feels like a little bit of work is needed to prepare a proposal for all the changes that need to happen across the combobox
<jugglinmike> Matt_King: I think my proposal for at least two of the comboboxes is that we remove any use of aria-selected because (as jongund pointed out) it's not doing anything
<jugglinmike> Matt_King: I think that would be true in this combobox and the list+autocomplete combobox. I'm not so sure about the other comboboxes, though
<jugglinmike> Matt_King: I'd like to take the minutes from this meeting and audit the other combobox examples and look at this behavior in all of them
<jugglinmike> Matt_King: I think we need a complete proposal for the changes this would entail to them all. Though I don't think we necessarily should do that all in a single pull requests (especially considering the corresponding test changes it will likely entail)
<Jem> https://www.w3.org/TR/wai-aria-1.2/#option
<jugglinmike> Matt_King: I want to re-read everything that I and others have written about "option"
<jugglinmike> Zakim, end the meeting