Listbox with Multiple Selection: "Recommended selection model" is uncommon

[JAWS-test]

https://w3c.github.io/aria-practices/#Listbox:

Two operating concepts are presented and only one of them is recommended and implemented in the example. I understand that the recommended one is much easier to operate with mouse and keyboard However, the problem is that the non-recommended operating concept is the familiar one, because native multiple select works exactly the same way on the web and desktop. Since an AT user can't tell if it's a native or ARIA listbox, she or he will always try the default operation first, which then doesn't work in the example linked here. As long as the default operation does not match the operation recommended here, a note be added to the page (e.g., "The operation is recommended because it is easier for mouse and keyboard users. However, it has the disadvantage that it does not correspond to the standard and must therefore be learned first. Therefore, operating instructions should be provided to users").

[smhigley]

Hi! It's a good point that the recommended keyboard implementation differs from the behavior of <select multiple>. I took a look through some of the other ARIA patterns that correspond to native HTML elements, and the closest spec note I could find that addresses differences between ARIA and HTML is this, in the Radio Group pattern:

NOTE
The initial focus behavior described above differs slightly from the behavior provided by some browsers for native HTML radio groups. In some browsers, if none of the radio buttons are selected, moving focus into the radio group with Shift+Tab will place focus on the last radio button instead of the first radio button.

I would be interested to hear what others think about adding a similar note to listbox, mentioning the difference between the recommended multiple selection pattern and the native <select multiple>.

I think that would be a good idea, though I'd lean towards having it be more neutral, and just address that there is a difference. Regarding this proposed wording:

However, it has the disadvantage that it does not correspond to the standard and must therefore be learned first.

I actually think that this isn't a disadvantage -- in user studies I've conducted, the native <select multiple> behavior was unexpected, confusing, and sometimes entirely blocking. The native multiselect actually performed by far the worst of all multiple selection comboboxes tested: https://www.24a11y.com/2019/select-your-poison-part-2/ TL:DR; it had only a 25% success rate. If anything, it might be the native behavior that needs a warning 😄. Though in actuality I think it'd be better if we forgoed commenting on the UX entirely, since we don't have similar warnings on other patterns that may cause UX struggles in the wild.

[smhigley]

Proposed wording:

NOTE
The selection behavior demonstrated differs from the behavior provided by browsers for native HTML <select multiple> elements. The select element behavior is to alter selection with unmodified up/down arrow keys, requiring the use of modifier keys to select multiple options. This example demonstrates a multiple selection pattern that does not require the use of modifier keys.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Multi-Select Listbox Keyboard Guidance.

The full IRC log of that discussion

<MarkMcCarthy> TOPIC: Multi-Select Listbox Keyboard Guidance
<MarkMcCarthy> https://github.com//issues/2193
<Matt_King> github: https://github.com//issues/2193
<MarkMcCarthy> Matt_King: essentially, this issue boils down to this selection model being less familiar than some others
<MarkMcCarthy> Matt_King: i'm not sure i agree with the premise but i want to discuss this with the group
<MarkMcCarthy> Matt_King: first question I have is: is there agreement or disagreement that the model we're using for listbox is unfamiliar?
<MarkMcCarthy> sarah_h: i disagree, I think the APGs is better for usability, which I wrote about in more detail in my comment
<MarkMcCarthy> Matt_King: there are several patterns where we document this kind of multiselect behavior with shift+arrow keys, then if you press an arrow key WITHOUT shift your selection disappears - it's well documented elsewhere
<MarkMcCarthy> Matt_King: this begs the question - if we're gonna document it, should we demonstrate it or is it useful to demonstrate it? it's a lot of work...
<MarkMcCarthy> sarah_h: i don't think we should
<MarkMcCarthy> Matt_King: to me, the visual clue is that if the spacebar checks one (or when holding shift), and pressing an arrow key doesn't make checks go away, it feels very discoverable
<MarkMcCarthy> sarah_h: i'm not opposed to making a note that it's different from the native select pattern
<MarkMcCarthy> Matt_King: i thought we already had a note there
<MarkMcCarthy> sarah_h: under multiselection, it does mention authors may use different patterns or choose among those modifier keys - it doesn't explictly state that this pattern is different from the native pattern
<MarkMcCarthy> sarah_h: there's a note in the radiogroup pattern that notes differences between ours and native
<MarkMcCarthy> Matt_King: when we were thinking about a note, i was thinking about it going on the example
<MarkMcCarthy> sarah_h: me too - i think it makes more sense since the pattern shows BOTH
<MarkMcCarthy> Matt_King: so should the note say it's different from browser native behavior?
<MarkMcCarthy> sarah_h: i started drafting something before the meeting, maybe that would be good?
<MarkMcCarthy> [sarah read her note]
<MarkMcCarthy> Matt_King: i love that
<MarkMcCarthy> MarkMcCarthy: +1
<MarkMcCarthy> sarah_h: i'll add it to a comment on the issue
<MarkMcCarthy> sarah_h: and figure out a PR
<siri> +1
<MarkMcCarthy> Matt_King: maybe we'll put it under the notes section under the examples? or maybe accessibility features? You can decide which is most appropriate
<MarkMcCarthy> sarah_h: notes is probably fine
<MarkMcCarthy> MarkMcCarthy: +1
<MarkMcCarthy> Matt_King: would you make it a PR against the move-examples branch?
<MarkMcCarthy> Matt_King: that should sort out this issue then