[Combobox] Align the selection by mouse blur behaviour

[silviuaavram]

Hi! I am opening this issue to ask about a different behaviour between the select-only and editable combobox elements.

The behaviour in question: highlight an item with keyboard, so it stays highlighted, then mouse click outside the list (basically do a blur by mouse).

select-only combobox selects the highlighted item. autocomplete combobox does not select the highlighted item.

Is there a specific reason to have a different behaviour between them? I would expect that the behaviour is the same, and the behaviour should be not to select the highlighted item on mouse blur. I would, however, expect the highlighted item to be selected when blurring by Tab, but this works correctly, so no further action here.

Autocomplete: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-autocomplete-list/ Select Only: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/

What do you think? As always, I'm happy to help with a PR to fix if we agree on the correct behaviour. Thank you!

[a11ydoer]

@curtbellew will test - to check how Chrome, Firefox, and Safari behave with a native HTML select- and report back to the group.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Mouse behavior differences between Select-only and editable combobox.

The full IRC log of that discussion

<jugglinmike> Topic: Mouse behavior differences between Select-only and editable combobox
<jugglinmike> github: https://github.com/w3c/aria-practices/issues/2966
<jugglinmike> Matt_King: My intuition was the opposite of the intuition of the reporter
<jugglinmike> Matt_King: I assumed that it WOULD select it because it was selected by the keyboard
<jugglinmike> Matt_King: The last person I remember talking a lot about using both mouse and keyboard was our friend at Norton--his name escapes me, now
<jugglinmike> Matt_King: It was about how many people would arrow down with the combobox but then blur with the mouse
<jugglinmike> Matt_King: Personally, though, I don't know what's reasonable here
<jugglinmike> CurtBellew: Honestly, I would expect it to work the same way as if I was using the keyboard, arrowing down, and then tabbing out
<jugglinmike> CurtBellew: Why would clicking out be different from tabbing out?
<jugglinmike> Matt_King: Would you be willing to check how Chrome, Firefox, and Safari behave with a native HTML select?
<jugglinmike> CurtBellew: Sure! I'd like to know, anyway
<jugglinmike> Matt_King: Great. We can put this back on the agenda in a couple weeks (since we're not meeting next week). We can follow the browsers' lead if they're consistent. If they're NOT consistent, then we'll have to have more of a discussion
<jugglinmike> Zakim, end the meeting

[curtbellew]

I did some quick tests in both Windows and Macos using a standard HTML Select. In each case I used the keyboard to bring focus to the select, opened the options, used up and down arrow keys to change the highlighted value, then clicked outside the select with my mouse. On Macos I was able to open the options by hitting the down arrow whereas on Windows I held down the Alt key and used the down arrow to open the options.

Macos - Chrome - returns to the initial value Safari - returns to the initial value Edge - returns to the initial value Firefox - returns to the initial value

Windows - Chrome - selects whatever was highlighted Edge - selects whatever was highlighted Firefox - selects whatever was highlighted

`Choose a car:

Volvo Saab Opel Audi `

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Mouse behavior differences between Select-only and editable combobox.

The full IRC log of that discussion

<jugglinmike> Topic: Mouse behavior differences between Select-only and editable combobox
<jugglinmike> github: https://github.com/w3c/aria-practices/issues/2966
<jugglinmike> Matt_King: Curt_Bellew did some work on this
<Jem> https://github.com/w3c/aria-practices/issues/2966#issuecomment-2124992753
<jugglinmike> Matt_King: When someone changes which option is highlighted in the list of options using the keyboard. So the value isn't actually set at this moment. Then, they click outside of the combobox
<jugglinmike> Matt_King: Because the click closes the dropdown, should that impact the selected value?
<jugglinmike> Matt_King: In other words, should clicking outside be treated like "enter"/"tab" or like "escape"?
<jugglinmike> Matt_King: So we were wondering what browsers do for standard selects
<jugglinmike> Matt_King: Chrome and Firefox on macOS both return to the initial value, (treating it like "escape")
<jugglinmike> Matt_King: Windows does the opposite
<jugglinmike> Matt_King: This is not what I was expecting!
<jugglinmike> Matt_King: If we were going to have our combobox mimic the behavior based on the platform... We could do that, but it feels batty to me
<jugglinmike> [general discussion]
<jugglinmike> jongund: I don't think it should be operating-system dependent
<jugglinmike> s/think it/think the behavior of the APG's combobox/
<jugglinmike> Matt_King: The select-only combobox behaves like Windows. The auto-complete combobox behaves like macOS.
<jugglinmike> Matt_King: So we have inconsistencies between our examples
<jugglinmike> Mark_McCarthy: I agree with jongund. We should choose one operating system to mimic
<jugglinmike> Bryan_Garaventa: I think the two examples should match
<jugglinmike> jongund: It seems like clicking outside the box is more like hitting "escape", conceptually
<jugglinmike> Matt_King: I agree. If the user is expressing an intent, it seems like it's "get me out of here"
<jugglinmike> Matt_King: (None of this affects screen reader users because we can't click outside of the box, even if we wanted to.)
<jugglinmike> jugglinmike: It may be that some users (particularly sighted users) don't recognize that highlighting an item is not the same as selecting it. From that perspective, it would be surprising for selection *not* to occur after clicking outside
<jugglinmike> Matt_King: It sounds like collectively, we have a preference for making this behave like "escape" (which is how the native element behaves on macOS)
<jugglinmike> Jem: In my opinion, I think it's important to have consistency in APG.
<jugglinmike> Matt_King: In terms of prioritization, I am adding the "bug" label to this issue, now
<jugglinmike> Matt_King: In terms of the severity of the bug, this is clearly not a blocking problem. It seems like a sub-3 kind of bug. It's an inconsistency, but it's an inconsistency that's hard to find
<jugglinmike> Matt_King: I'm going to label this "P3" for now; does anyone disagree?
<jugglinmike> Jem: I really don't like the inconsistency, but I'm okay with that