Building a multi-select component

January 18, 2022 Article

A foundational overview of how to build a responsive, adaptive, and accessible, multiselect component for sort and filter user experiences.

Oct 13, 2021

In this post I want to share thinking on a way to build a multi-select component. Try the demo.

Demo

If you prefer video, here’s a YouTube version of this post:

Overview #

Users are often presented with items, sometimes lots of items, and in these cases it can be a good idea to provide a way to reduce the list to prevent choice overload. This blog post explores filtering UI as a way to reduce choices. It does this by presenting item attributes that users can select or deselect, reducing results and therefore reducing choice overload.

Interactions #

The goal is to enable swift traversal of filter options for all users and their varying input types. This will be delivered with an adaptable and responsive pair of components. A traditional sidebar of checkboxes for desktop, keyboard and screen readers, and a for touch users.

This decision to use built-in multiselect for touch, and not for desktop, saves work and creates work, but I believe delivers appropriate experiences with less code debt than building the entire responsive experience in one component.

Touch #

The touch component saves on space and helps user interaction accuracy on mobile. It saves space by collapsing an entire sidebar of checkboxes into a built-in overlay touch experience. It helps input accuracy by showing a large touch overlay experience provided by the system.

Keyboard and gamepad #

Below is a demonstration of how to use a from the keyboard.

This built-in multi-select can’t be styled and is only offered in a compact layout not suitable for presenting a lot of options. See how you can’t really see the breadth of options in that tiny box? While you can change its size, it’s still not as usable as a sidebar of checkboxes.

Markup #

Both components will be contained in the same

element. The results of this form, whether checkboxes or a multi-select, will be observed and used to filter the grid, but could also be submitted to a server.

form>form>

Checkboxes component #

Groups of checkboxes should be wrapped in a

element and given a

. When HTML is structured this way, screen readers and FormData will automatically understand the relationship of the elements.

form>
fieldset>
legend>Newlegend>
… checkboxes …
fieldset>
form>

With the grouping in place, add a and for each of the filters. I chose to wrap mine in a

so the CSS gap property can space them evenly and maintain alignment when labels go multiline.

form>
fieldset>
legend>Newlegend>
div>
input type="checkbox" id="last 30 days" name="new" value="last 30 days">
label for="last 30 days">Last 30 Dayslabel>
div>
div>
input type="checkbox" id="last 6 months" name="new" value="last 6 months">
label for="last 6 months">Last 6 Monthslabel>
div>
fieldset>
form>

A screenshot with an informative overlay for the legend and fieldset elements, shows color and element name.

component #

A seldom used feature of the element is multiple. When the attribute is used with a element, the user is allowed to choose many from the list. It’s like changing the interaction from a radio list to a checkbox list.

form>
select multiple="true" title="Filter results by category">
…
select>
form>

To label and create groups inside of a , use the element and give it a label attribute and value. This element and attribute value are akin to the

and

elements.

form>
select multiple="true" title="Filter results by category">
optgroup label="New">
…
optgroup>
select>
form>

Now add the elements for the filter.

form>
select multiple="true" title="Filter results by category">
optgroup label="New">
option value="last 30 days">Last 30 Daysoption>
option value="last 6 months">Last 6 Monthsoption>
optgroup>
select>
form>

A screenshot of the desktop rendering of a multi-select element.

Tracking input with counters to inform assistive technology #

The status role technique is used in this user experience, to track and maintain the tally of filters for screen readers and other assistive technologies. The YouTube video demonstrates the feature. The integration begins with HTML and the attribute role="status".

div role="status" class="sr-only" id="applied-filters">div>

This element will read aloud changes made to the contents. We can update the contents with CSS counters as users interact with the checkboxes. To do that we first need to create a counter with a name on a parent element of the inputs and state element.

aside {
counter-reset: filters;
}

By default, the count will be , which is great, nothing is :checked by default in this design.

Next, to increment our newly created counter, we’ll target children of the

element that are :checked. As the user changes the state of inputs, the filters counter will tally up.

aside :checked {
counter-increment: filters;
}

CSS is now aware of the general tally of the checkbox UI and the status role element is empty and awaiting values. Since CSS is maintaining the tally in memory, the counter() function allows accessing the value from pseudo element contents:

aside #applied-filters::before {
content: counter(filters) " filters ";
}

The HTML for the status role element will now announce “2 filters ” to a screen reader. This is a good start, but we can do better, like share the tally of results the filters have updated. We’ll do this work from JavaScript, as it’s outside what counters can do.

A screenshot of the MacOS screen reader announcing number of active filters.

Nesting excitement #

The counters algorithm felt great with CSS nesting-1, as I was able to put all the logic into one block. Feels portable and centralized for reading and updating.

aside {
counter-reset: filters;& :checked {
counter-increment: filters;
}
& #applied-filters::before {
content: counter(filters) " filters ";
}
}

Layouts #

This section describes the layouts between the two components. Most of the layout styles are for the desktop checkbox component.

The form #

To optimize legibility and scannability for users, the form is given a maximum width of 30 characters, essentially setting an optical line width for each filter label. The form uses grid layout and the gap property to space out the fieldsets.

form {
display: grid;
gap: 2ch;
max-inline-size: 30ch;
}

The element #

The list of labels and checkboxes both consume too much space on mobile. Therefore, the layout checks to see the user’s primary pointing device to change the experience for touch.

@media (pointer: coarse) {
select[multiple] {
display: block;
}
}

A value of coarse indicates that the user will not be able to interact with the screen with high amounts of precision with their primary input device. On a mobile device, the pointer value is often coarse, as the primary interaction is touch. On a desktop device, the pointer value is often fine as it’s common to have a mouse or other high precision input device connected.

The fieldsets #

The default styling and layout of a

with a

is unique:

A screenshot of the default styles for a fieldset and legend.

Normally, to space my child elements I’d use the gap property, but the unique positioning of the

makes it difficult to create an evenly spaced set of children. Instead of gap, the adjacent sibling selector and margin-block-start are used.

fieldset {
padding: 2ch;& > div + div {
margin-block-start: 2ch;
}
}

This skips the

from having it’s space adjusted by targeting just the


 children.

The filter label and checkbox #
As a direct child of a 
 and within the max width of the form’s 30ch, label text may wrap if too long. Wrapping text is great, but misalignment between text and checkbox is not. Flexbox is ideal for this.

fieldset > div {
display: flex;
gap: 2ch;
align-items: baseline;
}

Play more in this Codepen
The animated grid #
The layout animation is done by Isotope. A performant and powerful plugin for interactive sort and filter.
JavaScript #
In addition to helping orchestrate a neat animated, interactive grid, JavaScript is used to polish a couple of rough edges.
Normalizing the user input #
This design has one form with two different ways to provide input, and they don’t serialize the same. With some JavaScript though, we can normalize the data.

I chose to align the  element data structure to the grouped checkboxes structure. To do this, an input event listener is added to the  element, at which point it’s selectedOptions are mapped.

document.querySelector('select').addEventListener('input', event => {
// make selectedOptions iterable then reduce a new array object
let selectData = Array.from(event.target.selectedOptions).reduce((data, opt) => {
// parent optgroup label and option value are added to the reduce aggregator
data.push([opt.parentElement.label.toLowerCase(), opt.value])
return data
}, [])
})

Now it’s safe to submit the form, or in the case of this demo, instruct Isotope on what to filter by.
Finishing the status role element #
The element is only tallying and announcing filter count based on checkbox interaction but I felt it was a good idea to additionally share the number of results and ensure the  element choices are counted as well.
 element choice reflected in the counter() #
In the data normalization section, a listener was already created on input. At the end of this function the number of chosen filters and the number of results for those filters are known. The values can be passed to the state role element like this.

let statusRoleElement = document.querySelector('#applied-filters')
statusRoleElement.style.counterSet = selectData.length

Results reflected in the role="status" element #
:checked provides a built-in way of passing the number of chosen filters to the status role element, but lacks visibility to the filtered number of results. JavaScript can watch for interaction with the checkboxes and after filtering the grid, add textContent like the  element did.

document
.querySelector('aside form')
.addEventListener('input', e => {
// isotope demo code
let filterResults = IsotopeGrid.getFilteredItemElements().length
document.querySelector('#applied-filters').textContent = `giving ${filterResults} results`
})

Altogether this work completes the announcement “2 filters giving 25 results”.

Now our excellent assistive technology experience will be delivered to all the users, however they interact with it.
Conclusion #
Now that you know how I did it, how would you‽ 🙂
Let’s diversify our approaches and learn all the ways to build on the web. Create a demo, tweet me links, and I’ll add it to the community remixes section below!
Community remixes #
Nothing to see here yet!
Last updated: Oct 13, 2021— Improve article


READ Also :   Community highlight: Bramus Van Damme