You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's an extremely common pattern (and recommended for usability) when having a group of related checkboxes to also have a checkbox that represents the entire group, and operates both as an indicator of current status (), as well as a way to provide aggregate checking/unchecking functionality.
This pattern is recursive, as groups can be nested in other groups.
The behavior is:
Checking the aggregate checkbox checks all checkboxes in the group
Unchecking the aggregate checkbox unchecks all checkboxes in the group
Clicking on an indeterminate checkbox checks the aggregate checkbox and all checkboxes in the group
(un)checking a checkbox in the group updates the aggregate checkbox, such that:
If all checkboxes in the group are now checked: check aggregate checkbox
If all checkboxes in the group are now unchecked: check aggregate checkbox
If only some checkboxes in the group are now checked: make checkbox indeterminate
Every time the state of the aggregate checkbox changes, any aggregate checkboxes of parent groups also need to change
This pattern is currently insanely difficult to get right in the general case, not to mention making it accessible.
@scottaohara has previously proposed a <checkbox-group>, and that would be a nice high level primitive that would cover many common cases and fix the problems with <select multiple>. However, it's quite common for the group to spread a very large area of content or even the whole page, and semantically it doesn't make sense to wrap it all with a <checkbox-group>.
So I think it may make more sense to define a way to associate a checkbox with a group of checkboxes, and then have <checkbox-group> use that as a lower level primitive that it builds on. This is also related with #1014 as presumably that would be another element reference attribute.
Ideally, that should also implicitly apply the right ARIA referencing attributes as well.
The text was updated successfully, but these errors were encountered:
It's an extremely common pattern (and recommended for usability) when having a group of related checkboxes to also have a checkbox that represents the entire group, and operates both as an indicator of current status (), as well as a way to provide aggregate checking/unchecking functionality.
(Image courtesy of Apple HIG)
This pattern is recursive, as groups can be nested in other groups.
The behavior is:
This pattern is currently insanely difficult to get right in the general case, not to mention making it accessible.
@scottaohara has previously proposed a
<checkbox-group>
, and that would be a nice high level primitive that would cover many common cases and fix the problems with<select multiple>
. However, it's quite common for the group to spread a very large area of content or even the whole page, and semantically it doesn't make sense to wrap it all with a<checkbox-group>
.So I think it may make more sense to define a way to associate a checkbox with a group of checkboxes, and then have
<checkbox-group>
use that as a lower level primitive that it builds on. This is also related with #1014 as presumably that would be another element reference attribute.Ideally, that should also implicitly apply the right ARIA referencing attributes as well.
The text was updated successfully, but these errors were encountered: