skip to content

On a hotel booking site, a parent 'Accessibility features' checkbox controls six amenity checkboxes; how should its mixed state look and behave?

level: middleimportance: should knowfreq 48%

answer

  1. derived, not chosen
  2. all, some, none
  3. a dash, not a tick
  4. activating it sets the whole group
  5. optional memory of the old mix

basics

~20 s

The parent shows checked when all six are checked, unchecked when none are, and mixed, drawn as a dash, when only some are. Activating it checks all six, or unchecks all when all were checked; mixed is derived, not picked.

solid answer

~40 s

The **mixed** (partially checked) state is a summary of the children, never a choice of its own. The parent is checked when all six amenities are checked, unchecked when none are, and mixed when some are, and it recomputes whenever a child changes. Activating the parent sets the whole group: from mixed or unchecked it checks all six, and from checked it unchecks all six. The Authoring Practices also describe an optional memory, where a third activation restores the partial set the guest had before. Visually, mixed needs its own mark, typically a horizontal dash, distinct from the tick and not signalled by colour alone, and assistive technology should announce it as mixed or partially checked. A lone checkbox with no children should never show mixed, and a switch cannot be mixed at all.

code

pseudocode · 12 lines
pseudocode
function parentState(children):
  checkedCount = count of children where child.checked
  if checkedCount == 0: return UNCHECKED
  if checkedCount == size(children): return CHECKED
  return MIXED

function onParentActivated(children):
  if parentState(children) == CHECKED:
    for each child in children: child.checked = false
  else:                      // UNCHECKED or MIXED
    for each child in children: child.checked = true
  render parent with parentState(children)

go deeper

for a junior

Recall the three parent states, all, some and none, and that mixed is drawn with its own mark such as a dash.

for a middle

Explain that the parent is derived from the children, walk through the activation cycle, and note the optional memory and why a switch cannot be mixed.

for a senior

Spot the production failures: parents that do not recompute, mixed used as 'unanswered', collapsed children hiding what mixed means, and inconsistent activation across teams.

for a principal

Decide whether the system supports tri-state parents at all, how deep nesting may go, and how the contract maps onto platforms that lack a native tri-state control.

## What the mixed state is A **checkbox** is normally dual-state: checked or not checked. The Authoring Practices also describe a **tri-state** checkbox with a third value, **partially checked**, called **mixed** in WAI-ARIA. Its standard use is a **parent checkbox** that represents and controls a group of child checkboxes, such as an 'Accessibility features' filter over six amenities: step-free access, roll-in shower, grab bars, visual alarms, hearing loop and lowered counters. ## Deriving the parent from its children The parent's state is **computed**, not stored separately. | Children checked | Parent shows | Meaning to the guest | |---|---|---| | All six | Checked | Every feature in the group is required | | Some (one to five) | Mixed | A subset is required | | None | Unchecked | No feature in the group is required | Every time a child changes, the parent recomputes. A parent that stays checked after a child is cleared is lying about the group. ## What activating the parent does The Authoring Practices say checking the overall checkbox checks all options in the group and unchecking it unchecks all. The common cycle is: 1. **Mixed** activated: all six become checked; the parent shows checked. 2. **Checked** activated: all six become unchecked; the parent shows unchecked. 3. **Unchecked** activated: all six become checked again. 4. Optionally, some implementations remember the partial set, so a third activation restores the guest's previous mix instead of repeating step 3. The optional memory is kind when people toggle by accident, but it makes the parent's behaviour harder to predict; a system that ships it should document it. ## Visual and announced form - Give mixed its **own mark**, conventionally a horizontal dash, distinct from the tick. - Do not rely on colour to separate mixed from checked; a tinted tick is not a different shape. - Assistive technology announces the state; the design spec should require that mixed is exposed as its own state, not reported as checked or unchecked. - Consider a count beside the parent label, such as 'Accessibility features (2 of 6)', so the summary is readable without expanding the group. ## Pitfalls - **Mixed on a lone checkbox.** Using mixed to mean 'not answered yet' on a checkbox with no children confuses everyone; an unanswered question needs a different control, such as radios with nothing pre-selected. - **Mixed on a switch.** A switch is on or off only; WAI-ARIA 1.2 says a mixed value is invalid for a switch and is treated as off. - **Hidden children.** If the children are collapsed or paged away, the guest cannot see what 'mixed' contains; show the count or expand the group. - **Deep nesting.** Three levels of tri-state parents are hard to reason about; keep the hierarchy shallow. - **Parent activation surprises.** If activating a mixed parent unchecks everything, a guest who wanted 'all' loses their picks; checking all first is the safer convention. ## In the hotel filter panel For the 'Accessibility features' group, a good spec combines the pieces: - The parent label carries a count: 'Accessibility features (2 of 6)'. - The group is expanded by default whenever any child is checked, so mixed never hides its contents. - Results update on the same timing model as every other filter in the panel, either instantly or on an explicit apply action, never a mix of the two. - 'Clear all filters' resets the children, and the parent follows through the same derivation rather than being written directly. These choices matter more than usual for this group: a guest who needs a roll-in shower is filtering for a requirement, not a preference, and a parent that misreports what is selected can lead to a booking that does not work for them. ## Across platforms Web and native mobile platforms both need a way to draw and expose a partially checked state; platforms differ in whether a tri-state control is built in, so some teams compose one. The contract to specify is platform-neutral: derived from the children, its own visual mark, its own announced state, and a documented activation cycle.

  • Should activating a mixed parent check everything or clear everything?
    Checking everything is the safer convention and matches the Authoring Practices' description that checking the overall checkbox checks all options. Clearing from mixed throws away the guest's picks with one tap. Whichever direction a system chooses, it should be the same everywhere and written into the component spec.
  • How would you test that a parent checkbox's mixed state reaches screen-reader users?
    Move focus to the parent in each of the three situations, all, some and none checked, and listen for the state announced: checked, mixed or partially checked, and not checked. Then change a child and return to the parent to confirm it recomputed. An automated scanner may confirm a state exists but cannot judge whether it matches the children.

saying these in an interview costs you the question

  • Mixed is a fourth option the guest can pick directly from the parent.
  • A tinted tick is enough to tell mixed apart from checked.
  • A switch can show mixed when some related settings are on.
  • The parent can keep its own stored state separate from the children.
  • Mixed is a good way to show that a lone checkbox is unanswered.