Consider creation of a "checkbox group"

[scottaohara]

While the topic of creating a <listbox> element has come up in open ui discussions in regards to create a replacement for <select multiple>, I've been thinking a lot lately about whether that's what's really needed.

For instance, I have frequently seen custom implementations of listboxes where an option visually conveys its current 'selected' state by use of checkmarks/checkboxes. This has lead to a few instances of people even getting temporarily tripped up by what is presented visually (apparently a list of checkboxes), vs what they actually hear - options which communicate a selected or not selected state - but typically not both when using a screen reader (e.g., not all screen reader users are 100% blind).

Listboxes are notorious for the manner in which their options' selected/not-selected states are conveyed by AT. Where some browser/screen reader combos will announce the "selected" state, and others will instead announce the "not selected" state, but not generally both.

Creating the concept of a "checkbox group" (potentially even a more generic 'toggle group' as there could be similar value for toggle buttons) could work similarly to that of both a listbox and radio button group as far as keyboard navigation is concerned. E.g., the group receives a single tab stop, arrow keys can be used to navigate the checkboxes, and space used to toggle the checked state. (might be a good use case for a focusgroup implementation?) Additionally, this could also programmatically expose the number of checkboxes within a particular group, or subgroup - this numeration is generally communicated by listbox options or radiobuttons in a group - but is not so with standalone checkboxes unless they have been nested in a list (e.g., <ul> element) - however in this case, depending on the way the checkboxes are navigated to, that numeration may not be exposed because it's not the checkboxes that expose this "x of y" information, but the parent list items that provide it.

Additionally, a checkbox group could do more than just provide visual parity with how some people are presently using single/multi-select custom listboxes. For instance, there are instances where someone might require a checkbox (maybe even a 1+checkboxes) within a group to be checked, but not ALL the checkboxes are required. Right now, authors must understand the nuances of setting up such a pattern to indicate at a group level that a number of checkboxes are required, but no actual individual checkbox is required. And then setup validation to check for their custom rule. An example of how one might implement this pattern today: https://codepen.io/scottohara/pen/abWWQmx

Another aspect a dedicated checkbox group could help solve for is a way to allow authors to communicate an indeterminate checkbox state without needing to roll their own functionality for this with JavaScript. Presently, the only way to indicate a native checkbox as in the indeterminate state is to use the IDL attribute and authors must script the other 'associated' checkboxes to listen to change events form that 'controller' checkbox. Similarly, the controlled checkboxes would need to check or uncheck based on a change event from the controller checkbox. People also have used custom listboxes with an initial "select all / deselect all" initial option to do similar, having to essentially fake an indeterminate state for options, as it is not possible to communicate such natively or with ARIA.

Edit: related to #113

[JAWS-test]

what should be considered when deciding whether a listbox or a checkbox group is better is the following difference:

• a listbox is one form element, a checkbox group consists of many form elements. thus, in the element overview of the screen reader, there is only one element (the listbox) or many elements (all checkboxes).
• when reading with the screen reader's virtual cursor, only the selected entries are output in the case of a listbox, and all entries are output in the case of a checkbox group.

[scottaohara]

based on how people could currently create this, yes @JAWS-test. but the idea here is not to just simply re-create what's currently possible, but to ideally create something that would allow for new baked in functionality and expectations. Otherwise, there's no point in the suggestion.

[travisleithead]

This made me wonder if the Toggle proposal's toggle-group covers this use case well? https://tabatkins.github.io/css-toggle/#toggle-group-property

[scottaohara]

i've read that a few times now. honestly, not sure though it does seem there are overlaps. seems something worth discussing at some point though... at the very least to figure out the various accessibility todos in the doc.

[scottaohara]

other thoughts that came up in talking with @aleventhal today:

• additional keyboard commands to allow for Home/End to quickly jump to the start/end of the checkbox group
• pressing the first letter(s) would allow for jumping to a checkbox whose label matched

essentially porting over some remaining single-select listbox behavior to this checkbox group proposal.

[github-actions]

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.

[scottaohara]

Randomly thinking about this today, but if moving forward with this, it'd be nice if it supported current input type=checkbox as well as any potential <checkbox> element that could come out of open ui

[github-actions]

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.

[lukewarlow]

Just came across this as I was thinking on indeterminate checkboxes. If there was a way to group checkboxes such that you could achieve that with pure html that would be brilliant.

As you mentioned a similar grouping idea could be useful for toggle buttons (though I think a specific toolbar element could be useful aswell?)

[lukewarlow]

A similar <radiogroup> element to wrap radio inputs and provide the name and required attributes for the whole group along with aria role of radiogroup would be good too? It would obviously also provide both focusgroup (and selection follow focus) semantics built in to match existing radio groups.

[github-actions]

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.