Consider adding documentation on `select[multiple]`

[querkmachine]

The <select> HTML element has an alternative mode that allows for selecting multiple values, also known as a multi-select listbox. This is enabled using the multiple flag. We don't explicitly support using multiple with our Nunjucks macro, however service teams can still enable it through the attributes parameter.

We do not support multiple in our CSS and discourage using it for a few reasons:

• Using multi-select is complicated, requiring the user to hold down one or more keyboard keys (⌘ Cmd/⌃ Ctrl or ⇧ Shift) whilst clicking on options. This is difficult to convey and usually not well understood by users.
• Multi-select cannot be easily used with keyboard navigation alone, practically requiring a pointer device to use.
• Multi-select is not (to my knowledge) well supported by assistive technologies.

We may also want to include information on the size attribute, which we also do not support in Frontend's code, although it doesn't have the same pitfalls as multiple.

Related documentation

Select

Suggestion

A user has suggested adding documentation about select[multiple]; specifically, adding information on why we discourage using it and don't support it: https://github.com/alphagov/govuk-frontend/issues/3317

In most situations, we would probably recommend using a list of checkboxes instead.

Evidence (where applicable)

• <select> your poison on 24 Accessibility

[mgladdish]

👋 I'm that user.

Note that, due to Nunjucks templates only working on Node, we're having to implement our own templates to generate compatible html for this design system. So we can't treat the values that macros accept as the 'spec' for what's supported by the design system, instead we have to work off the html equivalents and reverse-engineer nunjucks templates to infer the behaviour we need to re-implement on our side. And, as you say, attributes can be passed in via the macro anyway, so even that's not a useful interface to us to know what's supported and what is not.

So the html is the 'spec', and there's nothing to indicate that either the rows or multiple attributes are not supported. This could have saved me considerable time trying to understand why they didn't work when I was poking about trying to understand the reason behind #3317.

[dav-idc]

Note: The default mechanisms for <select multiple> are not accessible to people looking to use input methods that don't include a keyboard.

@calvin-lau-sig7 found a 2019 article by Sarah Higley which includes a section on how multi-select for select elements works.

The article describes the options for how to interact with a <select> element when selecting multiple options. If the article is still accurate today, then a key detail is that that you need to use a keyboard to select multiple options. It cannot be usably done via a mouse-only or single non-dragging pointer touch-only method.

If the only way to make multi-select usable is to involve a keyboard input device, then that means that <select multiple> fails a WCAG 2.1 AAA criterion: 2.5.6 Concurrent Input Mechanisms.

While we're not legally obligated to meet WCAG AAA success criteria, this one is pretty important for real-world accessibility. People should be able to interact with government services without requiring a keyboard as the input device.

@CharlotteDowns suggested we might want to add some guidance on why we don't use <select multiple>, and referenced this GitHub issue as a place to have that conversation.