Should select multiple with popup have OK/Cancel buttons?

[josepharhar]

Multi-select popups have some variations for committing the chosen options and closing the picker:

1. "OK" and "Cancel" buttons are both included in the popup.
   • Activating an option does not commit it until the "OK" button is pressed.
   • Pressing "OK" closes the picker and commits the selected options.
   • Pressing "Cancel" does not commit anything, effectively reverting changes.
   • This is how the native select multiple popup on android works.
2. Only a close button is provided.
   • Activating an option commits it immediately.
   • Pressing the close button closes the picker, just like light dismiss by clicking/touching outside the picker.
   • This is how the native select multiple popup on iOS works.
3. No buttons provided.
   • Activating an option commits it immediately.
   • Picker can only be closed by light dismiss or clicking on the invoker button.
   • This is how the select multiple popup in issues.chromium.org works (see the "OS" label on any bug)

Not providing any buttons would be the easiest to implement and standardize.

If we provide buttons automatically in the UA shadowroot of the select's picker, should we make it configurable to switch between option 1 and option 2? This would require more work.

In my opinion, implementing option 2 would be the best since it's not too hard to implement and customize and provides good defaults/affordances.

In my opinion, option 3 is the best because it ensure that light dismiss commits options, raises less questions to me about how to implement the accessibility mapping of the popup element, doesn't require us to implement and standardize additional buttons, and should still make it possible for authors to implement their own buttons if they want them.

[lukewarlow]

Option 2 seems the least useful tbh (because customisation would be limited). We could just provide a hidePicker() method and people can add it themselves (wouldn't need to be keyboard accessible so the nested interactives wouldn't necessarily be an issue as they'd have escape?).

Unless I'm missing something which is possible.

[josepharhar]

Option 2 seems the least useful tbh (because customisation would be limited).

We could expose a pseudo-element to target it, and you could display:none it to get the "option 3" behavior

wouldn't need to be keyboard accessible so the nested interactives wouldn't necessarily be an issue as they'd have escape

So it would be a div with some text or a symbol that isn't keyboard focusable, and it has an onclick event listener to close the picker? I guess that makes sense, but I also wonder what the keyboard focusability and a11y mappings of the close button in option 2 should be.

This sounds like option 3, which would certainly be the easiest to standardize since it's basically do nothing, so I'm not super opposed to that.

[josepharhar]

Another question I have is if we have an ok/cancel/close button, what should the a11y role mappings be? For single select we have a menulist popup and change it to dialog if there are interactive elements like a button. If we provide this button by default, should the mapping always be a dialog?

[josepharhar]

Some reasons to not provide ok/cancel buttons (option 3):

• Users may expect light dismiss to commit the options
  • If there is an "ok" button, then the user has to press it in order to commit the options, and light dismiss doesn't commit them.
  • I have ran into this issue with the time picker on android, it took me many attempts to learn.
• Developers can still add these buttons if they want them
  • It might be a little challenging to add an "ok" button which must be pressed in order to commit the options. It would probably be easiest to revert the changes if the picker is closed in other ways besides the "ok" button.
  • We could by default not fire a change event until the picker is closed anyway, but still fire input events every time the user clicks an option.

[css-meeting-bot]

The Open UI Community Group just discussed Should select multiple with popup have OK/Cancel buttons?, and agreed to the following:

• RESOLVED: choose option 2 for now, where there is one button which commits the options and closes the picker. light dismiss will also commits the options and close the picker.

The full IRC log of that discussion

<masonf> jarhar: scott wrote this up a while ago for menu elements, and it got me thinking about select multiple.
<masonf> jarhar: what should the behavior be for select multiple - should it stay open? If so, how do you commit the options you've selected?
<masonf> jarhar: different implementations I've seen on native and web. Three options. One is picker has ok/cancel button. Pick all options, then click OK.
<masonf> jarhar: Cancel undoes the changes you made.
<masonf> jarhar: that's what native picker on android does today, e.g. time picker.
<masonf> jarhar: another option: just have cancel button. Open picker, choose what you want, cancel closes the picker. But also so does light dismissing. No way to revert changes.
<masonf> jarhar: what's what iOS select multiple picker does today.
<masonf> jarhar: third option: no buttons, just options. Only way to close is to click the invoking button or light dismiss. No way to undo.
<masonf> jarhar: pros and cons. Having ok/cancel can be annoying.
<masonf> jarhar: Android native calendar app has a time picker that I use often. First 5-10 times I did this, I light dismissed, and was annoyed to find it cancelled my changes.
<masonf> jarhar: Having no buttons to close the picker is also weird, because you have to know to light dismiss it.
<masonf> q+
<masonf> jarhar: buganizer select multiple does this, and takes getting used to.
<masonf> jarhar: having just cancel button makes sense, but having any buttons at all needs more work. New pseudo elements. A11y mapping questions. Etc.
<masonf> jarhar: for customizable select, the role is set differently if there are interactive elements (like a cancel button).
<frehner> q+
<masonf> jarhar: should menulist handle this differently, etc.
<masonf> jarhar: given all of the above, no buttons sounds the most appealing.
<scott> q+
<masonf> jarhar: also curious about a11y
<jarhar> masonf: i dont like the buttons. the one question about having no buttons is that the user has to learn how to close the thing. the counterpoint i would like to make is that most users already assumed that. we recently added the closedby attribute to dialogs because users expected light dismiss to work.
<jarhar> masonf: the frustrating part that i really hate about having ok buttons is the same one that caused the closedby attribute. you do the easy thing which is close outside it, then you have to find the button to click, then you have to figure out what it means to close this thing. i think its simpler and more intuitive to just make light dismiss work
<masonf> ack mason
<jarhar> masonf: adding buttons scares me a bit from the a11y pov. i dont want to make every menu become a dialog, it seems easier if that doesnt happen
<masonf> ack frehner
<masonf> frehner: curious about the committed side of things. If selections aren't committed (with buttons) - is that an issue with developers observing changes?
<masonf> frehner: e.g. adding more business rules about what can be selected.
<masonf> jarhar: I did talk to Mason about this and once we choose whether to have buttons, we can build on this.
<masonf> jarhar: while the picker is open, fire `input` events but not `change` events. If we need cancel, reset and then fire cancel.
<masonf> jarhar: developer should see what is being chosen along with what "was" chosen.
<masonf> q?
<masonf> ack scott
<masonf> scott: one reason I mentioned buttons is specifically for situations where e.g. a listbox picker is single-select. If you had it appear and then make selections but it stays visible, you wonder how to get it to go away.
<sarah> q+
<masonf> scott: particularly with a mouse. For keyboard, pressing ESC means I want to undo what I just did.
<masonf> scott: how do you teach someone that this is different than normal. Also how to do this with touch.
<masonf> scott: maybe swiping makes them stuck until they make a selection. Android we could rely on the back button. Does that mean dismiss or cancel/undo?
<masonf> scott: most straightfoward solution would be to add a "confirm" button. What does that mean for a11y and usability. Maybe not needed, but similar to ARIA-WG discussion about how to put up an example for this.
<masonf> scott: how to make accessible multi-select picker. No agreement on how to do that without also going against existing rules, e.g. no buttons inside listbox.
<masonf> scott: Dominic responded to updated PR for menulist about small screen devices. When the menulist takes up the whole screen, what then?
<masonf> scott: question about when you can't tap outside.
<masonf> q?
<masonf> sarah: this works nicely on desktop, but not mobile. How about if there was a button on mobile only?
<masonf> sarah: select has always been different on mobile vs. desktop
<jarhar> q+
<masonf> sarah: there are form factor reasons
<masonf> sarah: not having the ok button on desktop works nicely. Without a pointer, just tab out. multi-select combos which don't go away - no issues on desktop
<masonf> ack sarah
<masonf> ack jarhar
<masonf> jarhar: thanks for the feedback. If we have close button on one platform, it should be on all. We do have some minimum size constraints so select is tappable.
<masonf> jarhar: we always try to do the same on mobile and desktop. Media queries let developers do different things if they want.
<masonf> jarhar: so buttons should be there on all platforms.
<masonf> jarhar: sad to hear that listboxes can only have options. So not sure how to do this. Perhaps we could have popup have a listbox inside it, with a close button outside the listbox. Scott, ok?
<sarah> q+
<masonf> scott: I can't say whether that'd be ok now. But there has often been a situation where ARIA spec says "you can do this" but people want to do more. Problem is that developers try to do the new things, without any cow path to follow, browser can't do the right thing and things are broken.
<masonf> scott: browser could render stuff the right way, but they're in a different place in the a11y tree. Maybe that's ok.
<masonf> scott: someone could arrow through all options, tab key gets them to the dismiss button. Or maybe the button isn't even in the tab order, and only for touch device users or something.
<masonf> scott: I can't say it'd be ok, but we should consider these options and then ask how well it works.
<masonf> scott: I can bring this to ARIA-WG to ask the question. Etc.
<masonf> sarah: I agree - whatever we do has to push the ARIA spec in some way. If there's an ok or ok/cancel button, this would have to be a dialog in some way. Perhaps buttons outside listbox. Putting buttons inside listbox causes problems.
<masonf> sarah: keyboard behavior: is this only for mouse users and touchscreen users? It would merit an ARIA-WG discussion and user studies.
<masonf> sarah: with comboboxes, if you do one wrong thing, things fall apart spectacularly. So we need to be careful setting precedents here.
<masonf> ack sarah
<masonf> sarah: let's test. Also question: nobody wants different behavior on mobile, to make developers do that explicitly always? Seems bad.
<masonf> q+
<masonf> jarhar: I hope that doesn't happen. If we have a single button, it can be on desktop and mobile and that's ok? Maybe?
<masonf> jarhar: if we had no button in either place, would people be unhappy?
<masonf> sarah: it's a lot harder to close on mobile. On desktop there are many options. Screen reader is soft-confined to popup.
<masonf> sarah: how do you get out of it, using voiceover for example?
<masonf> ack mason
<jarhar> masonf: we did talk about with customizable select single select, we did talk about having mobile - you might want it to take up the full screen and look kind of different. we have a ua stylesheet with media queries in it
<jarhar> masonf: the popup would show fullscreen. its not the same issue as this, but it was about having different behavior on mobile or small screens
<jarhar> masonf: the counterpoint was that actually makes it harder for developers to undo it and do the right thing
<jarhar> masonf: the counterpoint was to make it very easy for developers to do the right thing
<jarhar> masonf: i dont know if this is the right thing for this button
<jarhar> masonf: the point of the media query for mobile was to make it easier to use. maybe this is similar, and maybe the answer is the same
<jarhar> masonf: if we have buttons, we should have them everywhere
<jarhar> masonf: i think joey said, on some native pickers like the ios picker, is it how do you get out of the menu? are there examples of mobile ?
<masonf> jarhar: on iOS I posted a video in the issue. When you tap the options, it commits the value immediately. Light dismiss (tap outside, or pressing X) keeps them committed.
<masonf> q?
<masonf> jarhar: leaning toward a single button that commits and closes
<masonf> jarhar: I have enough to go on
<masonf> masonf: also light dismiss would commit and accept?
<masonf> jarhar: yes
<masonf> jarhar: still questions about keyboard behavior.
<masonf> scott: seems worth trying
<jarhar> proposed resolution: choose option 2 for now, where there is one button which commits the options and closes the picker
<jarhar> proposed resolution: choose option 2 for now, where there is one button which commits the options and closes the picker. light dismiss will also commits the options and close the picker.
<sarah> +1
<masonf> +1
<scott> +1
<jarhar> RESOLVED: choose option 2 for now, where there is one button which commits the options and closes the picker. light dismiss will also commits the options and close the picker.

[josepharhar]

From the discussion with @keithamus in the joint meeting, it sounds like some authors will definitely want to have ok and cancel buttons, and customize light dismiss behavior to do things like prevent light dismiss entirely, make it cancel the changes, or make it commit the changes.

It sounded to me like we have 3 paths forward to address this:

• Build the buttons and behaviors into the browser, and add attributes to control the behaviors.
• Provide a way in the markup to put buttons before or after the listbox of options in the picker, so that the author can provide their own buttons and then hook up their own behaviors to those buttons.
• Don't work on select multiple with a picker for now and focus on shipping customizable select in-page (listbox mode) so that authors can build their own pickers and use customizable select in listbox mode inside their own picker.

Keith mentioned that sites will want to put lots of stuff in their pickers other than ok/cancel buttons, like a text input to filter, which is a reason not to build all the different modes/behaviors into the browser. Does all this sound right Keith?

[keithamus]

This sounds right. I'll reach out to some GitHub developers who might be able to share insight/user research on the "SelectPanel" component which drives Assignees/Reviewers/Labels/Projects etc in the GitHub sidebar, I think that was where a lot of good research around this happened.

[scottaohara]

maybe less is more here, tbh.

if in-page customizable multi-select can be created - then people can absolutely use that and include it in a dialog / dialog[popover] and then provide their own confirm / dismiss buttons.

no worries about all browsers creating interop with pseudo buttons and how to style them / how much they can be styled.

yes, devs need to still make sure they come up with an accessible way to expose the values chosen from whatever their invoking element is... but we were likely to not even cover all the different ways people might want to visualize that anyway.

[lukewarlow]

I tend to agree with Scott I think we should provide a combobox variant that's simplistic and if people want fancier ones then they can use the listbox variant and build a combobox component themselves?
We'll never meet all use cases, trying to meet some of the more complex ones will result in disappointment and add a lot of complexity.