Under-Engineered Multi-Selects

This post is not about <select multiple> nor a bunch of <div>s roled-up into a listbox with aria-multiselectable. Both the APG examples and native HTML control have tested poorly with users for more than two decades.

This post demonstrates a different way to let users select multiple choices from a set. Ideally one that is less confusing and more forgiving of mistakes. Nielsen Norman Group has a reasonably good post on the challenges with any approach, even though it mis-names nearly every control it shows (including the sin of using the word dropdown to mean at least two different things)

The Basic Pattern

Ok, with that exposition out of the way, here is the pattern:

See the Pen Under-Engineered Multi-Selectables by Adrian Roselli (@aardrian) on CodePen.

Basic pattern debug view.

Essentially it is a pile of checkboxes in a fieldset, with a link to skip past them all:

  <fieldset>
    <legend>Mammals</legend>
    <p>
      <a href="#Skip">Skip to next group</a>
    </p>
    <input type="checkbox" name="Mam" id="Mam01" value="Aardvark">
    <label for="Mam01">Aardvark</label>
    <input type="checkbox" name="Mam" id="Mam02" value="Babirusa">
    <label for="Mam02">Babirusa</label>
    <input type="checkbox" name="Mam" id="Mam03" value="Chipmunk">
    <label for="Mam03">Chipmunk</label>
    <input type="checkbox" name="Mam" id="Mam04" value="Douc">
    <label for="Mam04">Douc</label>
    …
  </fieldset>

The <fieldset> provides the grouping context, the <legend> provides the accessible / group name, and the link lets a keyboard user bypass the entire thing without having to tab through a gajillion checkboxes.

The checkboxes are native HTML, so operating them should be familiar while also providing a clear visual cue to what has and hasn’t been chosen. If you want checkboxes that look different from the browser defaults, read my post Under-Engineered Custom Radio Buttons and Checkboxen, which keeps native HTML checkboxes under the fancy design.

CSS grid handles layout so I don’t need to wrap everything in layout <div>s. It also keeps the text from wrapping under the checkbox. The only curveball is the skip link, which I have span both columns.

fieldset {
  display: grid;
  grid-template-columns: 1.5em auto;
  gap: .5em 0;
}

fieldset > * {
  align-self: start;
}

fieldset > p {
  grid-column: 1 / span 2;
  margin: 0 0 .5em 0;
}

To recap: checkboxes in a fieldset with a skip link using CSS grid and done.

You Hate Tall Content

You may not like that example if it is too tall for your page. Maybe you have a few of these in a sidebar and you want more than one to be visible at a time. Or you have a fixed height screen. Or you enjoy watching users scroll a small box inside a bigger box.

See the Pen Scrolling: Under-Engineered Multi-Selectables by Adrian Roselli (@aardrian) on CodePen.

Scrolling pattern debug view.

The first thing I do is is make the <fieldset> focusable by giving it a tabindex:

  <fieldset tabindex="0">
    <legend>Mammals</legend>
    …
  </fieldset>

Then I use that tabindex in my CSS selector:

fieldset[tabindex] {
  max-height: 11.5em;
  max-width: 20em;
  overflow: auto;
}

I set the overflow and max-height to turn it into a scrolling container. Ideally the height should partially clip the bottom visible choice as a visual cue that there are more. The max-width pulls the container scroll bar closer as another visual cue there are more choices — though both Safari on iOS and Chrome on Android do not show scroll bars (Chrome will show them during interaction), and Safari on macOS shows a horizontal scrollbar as well.

The selector relies on tabindex before setting the height in order to ensure a keyboard user can scroll the container. Since a <fieldset> already has the group role (implicitly) and accessible name (from <legend>), I don’t need to do anything beyond the tabindex in my selector. It is essentially the same technique as I use in Under-Engineered Responsive Tables.

No position: sticky is needed on the <legend> since it won’t scroll be default, staying persistently visible without occluding anything in the box.

To recap: checkboxes in a fieldset with a skip link using CSS grid, then making it a focus-stop to set a height, and done.

You Hate Tall Content and Fieldsets

Some folks don’t like fighting with CSS to get a <fieldset> to look like their favorite flat UI long shadow fluid brutalist masterpiece. That’s ok. You can still get the same effect with ARIA (and yet more CSS):

See the Pen Group Role: Under-Engineered Multi-Selectables by Adrian Roselli (@aardrian) on CodePen.

Scrolling ARIA container debug view.

There is a lot more happening here, some of it required by the change and some of it because I can. Let’s look at the necessary changes first, starting with the HTML:

  <div role="group" aria-labelledby="ScrollingGroupLabel" tabindex="0">
    <p>
      <strong id="ScrollingGroupLabel">Mammals</strong>
    </p>
    <p>
      <a href="#Skip">Skip to next group</a>
    </p>
    <input type="checkbox" name="Mam" id="Mam01" value="Aardvark">
    <label for="Mam01">Aardvark</label>
    …
  </div>

The group role replaces the grouping that the <fieldset> provided, while the aria-labelledby grabs the accessible name, which the <legend> had provided. I set the accessible name in <strong> so it will visually stand out if the CSS fails, making up for the lack of vertical offset the <legend> provided.

The original CSS selectors need to change as well. As above, and borrowing from my post Using CSS to Enforce Accessibility, I build the selector to ensure it has the role and an accessible name reference. I also add the border I lost by dropping <fieldset>:

[role="group"][aria-labelledby] {
  display: grid;
  grid-template-columns: 1.5em auto;
  gap: .5em 0;
  border: .1em solid #ccc;
  padding: 0 .75em;
}

The group name node that replaces the <legend> should not scroll with the rest of the group content. You could put it outside the group, but I am mimicking the <fieldset>/<legend> structure. As such, to prevent text overlap, it also needs an opaque background. That background needs to come from the page or container background. This is probably best handled with CSS custom properties:

:root {
  --page-bg: #eee;
  --text-color: #333;
}
[role="group"][aria-labelledby][tabindex] > p:first-child {
  position: sticky;
  top: 0;
  background-color: var(--page-bg);
}

Don’t forget to account for the controls that can appear behind the sticky group name (not an issue with <legend>). Use scroll-padding-top on the group to create a bit of a buffer.

If I am setting a background on everything then I might as well add the visual cue that this thing scrolls (but only when it has a tabindex, meaning a keyboard user can scroll it), thanks to styles from Lea Verou’s 2012 post:

[role="group"][aria-labelledby][tabindex] {
  max-height: 12.75em;
  max-width: 20em;
  overflow: auto;
  scroll-padding-top: 1em;
  background:
    linear-gradient(var(--page-bg) 30%, var(--page-bg)),
    linear-gradient(var(--page-bg), var(--page-bg) 70%) 0 100%,
    radial-gradient(farthest-side at 50% 0, rgba(0,0,0,.2), rgba(0,0,0,0)),
    radial-gradient(farthest-side at 50% 100%, rgba(0,0,0,.2), rgba(0,0,0,0)) 0 100%;
  background-repeat: no-repeat;
  background-color: var(--page-bg);
  background-size: 100% 4em, 100% 4em, 100% 1.4em, 100% 1.4em;
  background-attachment: local, local, scroll, scroll;
}

I also threw a default focus style into the mix, though I would assume any project where you use this will already have one. Right?

To recap: checkboxes in an ARIA group with a skip link using CSS grid, then making it a focus-stop to set a height, then a few more styles as visual cues while restoring lost fieldset and legend features, and done.

You Hate Tall Content and Fieldsets and Letting People Glance at Stuff

At this point we might as well go all in. Let’s hide all the choices, saving the maximum amount of space, and require the user to interact with a disclosure in order to browse them. This pattern leans on my post Disclosure Widgets.

See the Pen Disclosure: Under-Engineered Multi-Selectables by Adrian Roselli (@aardrian) on CodePen.

Disclosure version debug view.

Some features that are not already covered above or in the posts I have linked throughout:

• Before the JavaScript runs (or if it never runs):
  • the container is not collapsed — it fits into the flow of the page;
  • it generally matches the previous example, but instead of a group label in the box, the button acts as the visible and programmatic label.
• When the JavaScript runs:
  • styles kick in to collapse the box;
  • the box will then sit over the content when expanded;
  • the skip link is hidden;
  • a white background is added so it stands out more from the page;
  • the scroll shadows are dropped since the control purpose is more obvious;
  • the disclosure trigger becomes functional;
  • a counter appears in the button trigger that displays the number of selected items against the total.
• The counter is part of the accessible name of the control. However, as it updates the changes may not be announced by all screen reader combinations, though it is a better option than a live region.
• The disclosure can be dismissed by clicking outside of it (except in Safari), tabbing out of it, or pressing Esc. This example does not set focus anywhere when that happens, but you should.
• I dumped the grid styles and went for classic floats so the entire width of a choice, including below the checkbox, is the clickable label.
• The visual styles may be a bit close to other custom select-like controls, but hopefully the visible checkboxes are a cue this behaves differently.
• This does not support arrowing among items; I prefer letting the user be able to scroll the box to quickly see all the options.
• This is not supposed to be an attractive design. If you don’t like the design then change it, but probably keep the core features until you can test it with users.
• This is not production-ready code. Especially not the script.

To recap: checkboxes in an ARIA group with a skip link using CSS grid, then making it a focus-stop to set a height, then a few more styles as visual cues while restoring lost fieldset and legend features, then using script to enhance it to be hidden until a button is triggered while allowing it to be dismissed, and done.

In other words, still grouped checkboxes at its core.

Wrap-up

You may not need a complex, cumbersome, bloated multi-select widget (especially if managed by a third party that ignores accessibility bugs). HTML may have all you need.

With a little CSS and maybe some script you can turn a stack of checkboxes into a usable control that is able to adapt to your site’s visual design. Users will generally know what to expect, testing should be simplified, and there is one fewer library or component you will need to monitor and update.

Unlike some of my other posts on under-engineered controls and widgets, I am not wading into screen reader announcements, High Contrast Mode, internationalization, CSS logical properties, text expansion, responsive type, error states, conveying required states, dark mode, preferred methods to label the controls, browser bugs, how to style the scrollbars, and so on. I have covered all of those and more somewhere on this site already (as have so many others).

Go forth, prototype, and test with your users!