Tree selection vs Listbox vs Checkbox group vs Transfer list

Prefer tree selection when parent-child hierarchy changes what users need to find, reveal, or select, such as folders, nested permissions, product taxonomy, or organization units.

Tree selection live example Listbox live example Checkbox group live example Transfer list live example

Decision dimensions

Dimension	Tree selection	Listbox	Checkbox group	Transfer list
UI or UX	UI + UX - Hierarchical expandable selection tree	UI + UX - Visible selectable option list	UI + UX - Multiple-choice form control	UI + UX - Two-pane item transfer and selected-set review
UI guidance	Render a labelled tree with visible levels, branch expanders, parent versus leaf styling, active focus, selected or checked state, parent mixed state, and a summary for selected descendants hidden inside collapsed branches.	Render a labelled listbox container, visible options, active option styling, selected option state, optional grouped labels, empty or disabled states, and nearby help or error text.	Render visible native checkboxes with labels, checked states, group legend, select-all-that-apply hint, and group validation state.	Render two clearly labelled panes for available items and selected items, with item counts, selected-row state, disabled move state, and action buttons positioned between or near the panes.
UX guidance	Use tree selection when users need to choose one or more items from a meaningful hierarchy and the parent-child structure helps them find, understand, or batch-select nodes.	Use a listbox when users benefit from seeing the available options while moving focus through the list and selecting one or more static values.	Let users choose independent options and review the selected set before submitting.	Use a transfer list when users must build a selected set by moving items from one visible collection to another and then review what will be submitted.
Good UI	A permissions picker shows Workspace, Reports, Billing, and Security branches with disclosure controls, selected leaf nodes, a mixed Reports parent, and a selected-count summary on collapsed parents.	A Role listbox has a visible label, five role options, one active row, one selected row, concise option names, and a status line explaining whether focus or selection changed.	Visible checkboxes with large hit areas, persistent labels, group legend, and aligned helper text.	A permissions editor shows Available permissions on the left, Selected permissions on the right, selected counts in both headers, Add and Remove buttons between panes, and Move up and Move down controls for selected permissions.
Bad UI	A nested checkbox list uses indentation but no tree role, no active row, no branch expanded state, and no keyboard model beyond tabbing through every checkbox.	Each option row contains nested Edit and Delete buttons, making the listbox a broken table of actions.	Tiny custom boxes that are hard to target.	A form shows one long source list and a tiny submitted count, so users cannot review which items were moved before saving.
Good UX	A user focuses Reports, presses Right Arrow to open it, moves to Monthly revenue, presses Space to select it, and the Reports parent becomes mixed.	A user arrows from Analyst to Support, hears the active option change, then presses Select active option to commit Support.	Clicking the label toggles the checkbox.	A user selects Billing and Audit logs, activates Add, hears that two permissions moved to Selected, and focus stays in a useful place for adding another permission.
Bad UX	A user arrows through the permission tree to explore branches and accidentally changes selected permissions because selection follows focus in a multi-select tree.	A high-stakes role assignment saves as soon as focus moves while the user is only exploring options.	Using checkboxes for mutually exclusive choices.	A user removes the only required item and the form waits until final submit to reveal the selected set is invalid.
Best fit	Users choose one or more values from a meaningful hierarchy.	Users choose one option from a visible static list.	Users can choose zero, one, or many options.	Users build a selected set by moving items from an available collection to a selected collection.
Avoid when	The options are flat or only loosely grouped.	A native select, radio group, or checkbox group can satisfy the interaction.	Only one option can be selected.	The option set is short enough for a checkbox group.
Required state	Initial tree state with visible label and root-level nodes.	Empty or initial state with visible label and at least one option.	Unchecked option state.	Available list initial state with label, count, and selectable options.
Accessibility burden	Use role tree on the container and provide an accessible name.	Use role listbox on the container and role option on every selectable item.	Use programmatic labels for every checkbox.	Give each list pane a visible label and programmatic accessible name.
Common misuse	Using tree selection for a flat list where listbox, checkbox group, or multi-select would be simpler.	Using listbox when native select, radio buttons, or checkboxes would do the job with less risk.	Using checkboxes for mutually exclusive choices.	Using transfer list for a short yes-or-no set that should be checkboxes.

Tree selection

UI or UX: UI + UX - Hierarchical expandable selection tree
UI guidance: Render a labelled tree with visible levels, branch expanders, parent versus leaf styling, active focus, selected or checked state, parent mixed state, and a summary for selected descendants hidden inside collapsed branches.
UX guidance: Use tree selection when users need to choose one or more items from a meaningful hierarchy and the parent-child structure helps them find, understand, or batch-select nodes.
Good UI: A permissions picker shows Workspace, Reports, Billing, and Security branches with disclosure controls, selected leaf nodes, a mixed Reports parent, and a selected-count summary on collapsed parents.
Bad UI: A nested checkbox list uses indentation but no tree role, no active row, no branch expanded state, and no keyboard model beyond tabbing through every checkbox.
Good UX: A user focuses Reports, presses Right Arrow to open it, moves to Monthly revenue, presses Space to select it, and the Reports parent becomes mixed.
Bad UX: A user arrows through the permission tree to explore branches and accidentally changes selected permissions because selection follows focus in a multi-select tree.
Best fit: Users choose one or more values from a meaningful hierarchy.
Avoid when: The options are flat or only loosely grouped.
Required state: Initial tree state with visible label and root-level nodes.
Accessibility burden: Use role tree on the container and provide an accessible name.
Common misuse: Using tree selection for a flat list where listbox, checkbox group, or multi-select would be simpler.

Listbox

UI or UX: UI + UX - Visible selectable option list
UI guidance: Render a labelled listbox container, visible options, active option styling, selected option state, optional grouped labels, empty or disabled states, and nearby help or error text.
UX guidance: Use a listbox when users benefit from seeing the available options while moving focus through the list and selecting one or more static values.
Good UI: A Role listbox has a visible label, five role options, one active row, one selected row, concise option names, and a status line explaining whether focus or selection changed.
Bad UI: Each option row contains nested Edit and Delete buttons, making the listbox a broken table of actions.
Good UX: A user arrows from Analyst to Support, hears the active option change, then presses Select active option to commit Support.
Bad UX: A high-stakes role assignment saves as soon as focus moves while the user is only exploring options.
Best fit: Users choose one option from a visible static list.
Avoid when: A native select, radio group, or checkbox group can satisfy the interaction.
Required state: Empty or initial state with visible label and at least one option.
Accessibility burden: Use role listbox on the container and role option on every selectable item.
Common misuse: Using listbox when native select, radio buttons, or checkboxes would do the job with less risk.

Checkbox group

UI or UX: UI + UX - Multiple-choice form control
UI guidance: Render visible native checkboxes with labels, checked states, group legend, select-all-that-apply hint, and group validation state.
UX guidance: Let users choose independent options and review the selected set before submitting.
Good UI: Visible checkboxes with large hit areas, persistent labels, group legend, and aligned helper text.
Bad UI: Tiny custom boxes that are hard to target.
Good UX: Clicking the label toggles the checkbox.
Bad UX: Using checkboxes for mutually exclusive choices.
Best fit: Users can choose zero, one, or many options.
Avoid when: Only one option can be selected.
Required state: Unchecked option state.
Accessibility burden: Use programmatic labels for every checkbox.
Common misuse: Using checkboxes for mutually exclusive choices.

Transfer list

UI or UX: UI + UX - Two-pane item transfer and selected-set review
UI guidance: Render two clearly labelled panes for available items and selected items, with item counts, selected-row state, disabled move state, and action buttons positioned between or near the panes.
UX guidance: Use a transfer list when users must build a selected set by moving items from one visible collection to another and then review what will be submitted.
Good UI: A permissions editor shows Available permissions on the left, Selected permissions on the right, selected counts in both headers, Add and Remove buttons between panes, and Move up and Move down controls for selected permissions.
Bad UI: A form shows one long source list and a tiny submitted count, so users cannot review which items were moved before saving.
Good UX: A user selects Billing and Audit logs, activates Add, hears that two permissions moved to Selected, and focus stays in a useful place for adding another permission.
Bad UX: A user removes the only required item and the form waits until final submit to reveal the selected set is invalid.
Best fit: Users build a selected set by moving items from an available collection to a selected collection.
Avoid when: The option set is short enough for a checkbox group.
Required state: Available list initial state with label, count, and selectable options.
Accessibility burden: Give each list pane a visible label and programmatic accessible name.
Common misuse: Using transfer list for a short yes-or-no set that should be checkboxes.

Decision rules

Prefer tree selection when parent-child hierarchy changes what users need to find, reveal, or select, such as folders, nested permissions, product taxonomy, or organization units.
Prefer listbox when the options are a flat list and expansion, collapse, parent levels, aria-level, or branch selection would add unnecessary custom keyboard behavior.
Prefer checkbox group when every option can stay visible as a short flat independent set with native checkbox semantics and no tree navigation model.
Prefer transfer list when users are moving items into a separate selected destination set; tree selection keeps selected nodes in place inside the hierarchy.
Use tree selection over multi-select only when hierarchy itself is part of the task; do not nest groups merely to save vertical space.
If parent nodes can be selected, define whether selecting a branch selects descendants, only the branch, or enters a mixed state, and show that policy in the UI.
Do not put aria-expanded on leaf nodes; reserve expanded and collapsed state for nodes that actually own child treeitems.
In multi-select trees, keep focus and selection visually distinct; Arrow keys should move focus through visible nodes while Space or an explicit action changes selection.
Use aria-selected or aria-checked consistently for treeitem state; avoid mixing both unless the two states mean different visible things with separate controls.
Avoid using tree selection for ordinary site navigation, menus, file tables, or rich row management where disclosure navigation, menu, table, data grid, or tree grid is a better model.

Inspect live examples

Tree selection Listbox Checkbox group Transfer list

Failure modes

A nested checkbox list is styled like a tree but lacks tree, treeitem, group, expanded state, and Arrow-key focus movement.
Arrowing through the tree changes selected permissions immediately even though the user is only exploring branches.
A collapsed parent hides selected children without any selected or mixed indicator on the parent row.
Leaf nodes expose aria-expanded=false, so assistive technology announces them as collapsible parents.
A multi-select tree omits aria-multiselectable or leaves unselected selectable treeitems without explicit selected or checked state.
Filtering or lazy loading changes the visible hierarchy without aria-level, aria-posinset, or status feedback for newly loaded nodes.

Sources

WAI-ARIA APG Tree View Pattern
APG defines tree view hierarchy, expansion, focus movement, single and multi-select behavior, focus versus selection, typeahead, aria-activedescendant, labels, and selected-state properties.
MDN ARIA tree role
MDN documents tree role hierarchy, accessible names, aria-expanded placement, aria-multiselectable, focus versus selected state, keyboard navigation, and dynamic node properties.
MDN ARIA treeitem role
MDN documents treeitem selection with aria-selected or aria-checked, single versus multi-selection constraints, accessible names, group nesting, and JavaScript keyboard requirements.
MUI X Tree View selection
MUI documents practical tree selection modes, checkbox selection, multi-selection, leaf-only selectable items, controlled selected items, and selection-change tracking.

Verification

Last verified: 2026-06-09