Meeting minutes
<Jem> https://
Publication status
Matt_King: Current target is April 1 for next publication.
Matt_King: We want to move it to April 8
howard-e: That works for me
Jem: I'm comfortable with that, too
Matt_King: Alright, then. Hearing no objections, we'll move the publication target to April 8
Combobox select vs focus issues
github: w3c/
Matt_King: We discussed this at the end of last week's meeting.
Matt_King: It didn't feel like we got to a place where we made decisions
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> w3c/
jongund: We were concerned about being consistent with standard select boxes
Matt_King: Basically, it does seem like a key question is whether or not selection should follow focus in the list box
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
Matt_King: That's the primary difference between the two. Is there a strong, good rationale for that?
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
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
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"
Matt_King: We have that behavior even though selection doesn't follow focus
Matt_King: For "down arrow", it just says it moves visual focus
Matt_King: This probably should say that "When it's visually indicated as selected (i.e. with a checkmark) [...]"
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
Matt_King: That's a very fast-fix bug, it's editorial, and it's important.
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
Matt_King: Just like what it says here in the documentation of "tab" in the example.
Matt_King: ...in the table "listbox popup keyboard support"
Matt_King: I know we had strong alignment on that behavior
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
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
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
Matt_King: If the edit box has a value, then you can't
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
Matt_King: That's a fundamental difference
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?
Matt_King: If it didn't filter, though, then that would break people's expectations
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: Maybe we should make the filtering dependent on whether a selection event occurred.
jongund: If aria-selected is following focus, then it doesn't really provide you with any additional information in this example
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
Jem: Yes
jugglinmike: Yes
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
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
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?
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
Matt_King: That's a good point
Matt_King: In the "combobox" section of the ARIA spec, there's nothing in the prose about aria-selected
Matt_King: So what jongund is suggesting would be in-line with the spec
Matt_King: Under "listbox", there's nothing in the prose about it
Matt_King: but it's under "inherited states and properties"
jongund: It looks like the "option" role REQUIRES aria-selected
Matt_King: In the latest version, aria-selected isn't required, it says it's "supported"
Matt_King: We changed this. In the current editor's draft, it's "supported" and not "required". It does not have an implicit value
Matt_King: This is a little tricky, but it's not meant to be!
Matt_King: What jongund suggested (removing aria-selected completely), I think it would be in-line with the other example, as well.
Matt_King: This meeting has turned into a deep-dive into the combobox, hasn't it?
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
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
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
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
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://
Matt_King: I want to re-read everything that I and others have written about "option"