Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

<select multiple> usability improvement suggestions #113

Open
aleventhal opened this issue Jun 18, 2020 · 24 comments
Open

<select multiple> usability improvement suggestions #113

aleventhal opened this issue Jun 18, 2020 · 24 comments
Assignees
@gregwhitworth
Labels
select-v2 Features regarding the second iteration of the selectmenu element

Comments

@aleventhal
Copy link

Problem

The <select multiple> built into HTML is difficult to use, both for AT (assistive technology) and non-AT users. The reasons for its current design are historical and date back to when the web was copying native Windows widgets from the 90s. There are very good reasons why most websites avoid <select multiple>, and prefer to use a JS-based widget that presents them as a list of checkboxes instead. Let’s move forward with a modern design.

Recommendation

Present <select multiple> as a set of checkboxes like JS widget libraries tend to do.

The Material List widget provides a good demonstration of this could work, see https://material.angular.io/components/list/overview#selection-lists
Standalone version: https://gxlepjxpdpr.angular.stackblitz.io

Problem Does a list of checkboxes solve the problem? How does it solve the problem?
Unclear visual model. On some platforms, it’s difficult to differentiate the currently focused item from something that is selected, as they may both use a background color change. Or, the focus may be a dotted outline that is hard to see. Yes Checkboxes are obvious. The difference between the currently focused item and a checked item is obvious (checkbox vs background color)
Unclear mouse model. Shift/ctrl/cmd click are unintuitive and rarely known Yes Everyone knows how to use a checkbox
Unclear keyboard model.Most understand don’t understand the need to use ctrl+click, ctrl+arrow, ctrl+space, shift+F8 (IE) Yes Up/down/space are easy to understand, intuitive from the presentation
Difficult multi-finger/multi-hand physical interactions for older users, people with physical disabilities Yes Click/up/down/space are easy and require only one hand
Easy to accidentally lose selection. Pressing an arrow key or clicking clears the entire selection. Yes Selection is retained when user navigates.

What about multiselect comboboxes?

Aka <select size=”1” multiple>

These currently don’t work in native HTML and must be implemented in JS. While we’re at it, let’s also enable these in browsers. A list of checkboxes works very nicely in a dropdown.
@aleventhal aleventhal mentioned this issue Jun 18, 2020
Open
@gregwhitworth
Copy link
Member

Thanks @aleventhal - I greatly appreciate you raising this. I'll work out a PR on a multiple section.

@gregwhitworth gregwhitworth self-assigned this Jun 18, 2020
@gregwhitworth gregwhitworth added the select These are issues that relate to the select component label Jun 25, 2020
@gregwhitworth
Copy link
Member

@smhigley as discussed - it would be cool if you could help with the research on this

@dandclark dandclark mentioned this issue Jan 25, 2022
Open
@scottaohara scottaohara mentioned this issue Mar 16, 2022
Open
@github-actions
Copy link

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

@github-actions github-actions bot added the stale label Mar 20, 2022
@aleventhal
Copy link
Author

aleventhal commented Mar 29, 2022 via email

@github-actions github-actions bot removed the stale label Mar 30, 2022
@jimmywarting
Copy link

I agree with every single thing in here.

select(multiple) need to have checkboxes and marking a row should be as simple as just pressing spacebar (without holding down extra modifier key, the angular material UI is so much better

the select(multiple) is so bad that no website use it today. I would like to see it making a comeback and rework the hole select(multiple)

@github-actions
Copy link

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

@github-actions github-actions bot added the stale label Nov 22, 2022
@josepharhar
Copy link
Collaborator

Recommendation
Present <select multiple> as a set of checkboxes like JS widget libraries tend to do.

Is this a recommendation to change the existing <select> element or to add a feature to the new <selectmenu> element? If it's for selectmenu then this issue should probably be merged into #447 right?

@NeilWix
Copy link

NeilWix commented Feb 14, 2023 via email

@aleventhal
Copy link
Author

aleventhal commented Feb 14, 2023 via email

@github-actions github-actions bot removed the stale label Feb 15, 2023
@scottaohara
Copy link
Collaborator

understood that it might not be how people initially think of interacting with checkboxes, but that doesn't mean it shouldn't be considered. see also #487

i quite like the idea of moving over to that sort of model, and I know it'd help a lot of inconsistent UX I've seen in large lists of checkboxes which either don't do anything to help facilitate quicker navigation (e.g., tab key navigates through them all) or arrow keys are implemented for navigating, but there's no programmatic or visible way to know this without guess and check interaction.

@josepharhar
Copy link
Collaborator

Select multiple was moved to v2 here, so I'm changing the labels: #531 (comment)

@josepharhar josepharhar added select-v2 Features regarding the second iteration of the selectmenu element and removed select These are issues that relate to the select component labels Feb 16, 2023
@github-actions
Copy link

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

@github-actions github-actions bot added the stale label Aug 16, 2023
@josepharhar
Copy link
Collaborator

I think that we are definitely going to use checkboxes for multi select

@github-actions github-actions bot removed the stale label Mar 22, 2024
@github-actions GitHub Actions
Copy link

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

@github-actions github-actions bot added the stale label Sep 19, 2024
@lukewarlow lukewarlow removed the stale label Sep 19, 2024
@aleventhal
Copy link
Author

@josepharhar is this on our radar? I don't think it's stale. It's a real a11y improvement for that control.

@lukewarlow
Copy link
Collaborator

One question I have for this? Should select multiple even be a listbox by default? It is today on desktop but at least in chrome and WebKit on mobile it's a more traditional in page trigger and a popover (like non multiple select). It would imo be good to have these be consistent. Though I recognise the option to have a listbox version (of both) would be good.

@aleventhal
Copy link
Author

Luke, it might be too big of a change for existing layouts to alter the default, because elements that would previously have had a large height would suddenly be very compressed vertically. On the other hand, adding a checkbox only increases the width a little bit, which the layout is more likely to adapt to (they generally have to because the width of options changes when the language changes).

@lukewarlow
Copy link
Collaborator

You're unfortunately probably right... Though perhaps it's currently so broken it would be acceptable?
I guess maybe we can change it for the appearance: base side of things even if not the proper default.

@aleventhal
Copy link
Author

aleventhal commented Sep 19, 2024 via email

@gregwhitworth
Copy link
Member

@lukewarlow @josepharhar keep me honest but we shouldn't have any compat issues with this since you have to opt-in to this experience with `appearance: base-select°. This frees us up a bunch to finally get the accessibility, performance and UX right.

Thank you for weighing in @aleventhal and the stale label just means that it hasn't had discussions in 6 months and forces trialing by chairs and the owner of the issue.

@aleventhal
Copy link
Author

aleventhal commented Sep 19, 2024 via email

@lukewarlow
Copy link
Collaborator

I personally think it's bad enough and inconsistent enough already (mobile Vs desktop and even the 3 mobile implementations all varying) that we could agree to change it to whatever design we think is best. Just changing how you select the options I think would be fine. And we could probably change (single listbox) to use radio buttons (in lieu of checkboxes) too?

@aleventhal
Copy link
Author

aleventhal commented Sep 19, 2024 via email

@josepharhar
Copy link
Collaborator

Changing the appearance:auto select multiple rendering in chromium is something that we can just decide to do because it is not standardized. We certainly should if there aren't significant compat issues, but there probably will be. Only one way to find out though.

I agree with Greg that the new appearance:base mode for select multiple will have checkboxes and solve these usability issues, and we don't have to worry about compat in that case because it is a new opt in.

I think that it should have a button and a popup just like the appearance:base-select we are implementing now, and I think that adding a size attribute should make it appear in-page without a button for both multiple and single selects. I'm not sure how that will be received by the standards groups though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@gregwhitworth gregwhitworth

Labels
select-v2 Features regarding the second iteration of the selectmenu element
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@gregwhitworth @jimmywarting @aleventhal @scottaohara @josepharhar @lukewarlow @NeilWix