Consider creation of a "checkbox group"

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 https://github.com/openui/open-ui/issues/113

Read the related issue 113, the WAI-ARIA listbox example, and the linked CodePen to compare current listbox and checkbox patterns. A completed investigation would define whether a checkbox group or broader toggle group is needed and specify its keyboard navigation, group-level validation, enumeration, and indeterminate-state behavior.