Quick Answer
A toggle group is a set of related toggle buttons that controls one or more active states.
Use a toggle group UI for compact, contextual choices such as:
- Grid, list, or table view.
- Left, center, or right alignment.
- Bold, italic, or underline formatting.
- A small set of filters that can be combined.
A toggle group can use one of two selection models:
- Single selection: only one item is active at a time.
- Multiple selection: any number of items can be active at the same time.
Do not choose a toggle group only because connected buttons look compact. First decide whether the controls represent actions, persistent settings, form values, navigation, or active tool states.
Toggle Group vs. Toggle Button
A toggle button is one button with a pressed or unpressed state. A toggle group organizes several related toggle buttons and defines how their states interact.
| Pattern | State model | Example |
|---|---|---|
| Toggle button | One independent pressed state | Show grid |
| Single toggle group | One active choice within a small set | Grid / List / Table |
| Multiple toggle group | Several independent pressed states | Bold / Italic / Underline |
The group adds meaning beyond visual proximity. Users need to understand what the controls have in common and whether selecting one item changes the others.
Toggle Group vs. Radio Group, Checkbox, Tabs, and Switch
Several controls can represent selection, but they create different expectations.
| Component | Best used for |
|---|---|
| Toggle group | Compact tool states, view modes, formatting, or contextual filters |
| Radio group | One submitted form value from a set of choices |
| Checkbox | Independent form choices or acknowledgements |
| Tabs | Moving between associated content panels |
| Switch | Turning a persistent setting on or off |
Use a radio group when the user is answering a form question such as "Shipping speed." Radio semantics clearly communicate that one value belongs to the field.
Use tabs when each option reveals its own content panel. A toggle group changes a state; tabs change which labeled panel is displayed.
Use switches for persistent settings such as notifications or location sharing. A compact row of switch-like controls should not be presented as a toggle group merely to save space.
Single-Selection Toggle Groups
A single-selection toggle group is useful when the interface has one active mode.
Examples:
- Grid, list, or table view.
- Left, center, right, or justified alignment.
- Day, week, or month calendar scale.
- Small, medium, or large preview size.
First decide whether an empty state is valid.
For a view selector, the interface is always showing some view. If "none selected" has no meaning, keep one option selected and prevent the active item from clearing itself.
For an optional filter, clearing the only active item may be meaningful. In that case, explain what the empty state does, such as "All results."
An exclusive toggle group can resemble a segmented control. The visual treatment should make the current choice obvious while keeping every alternative readable.
Multiple-Selection Toggle Groups
A multiple-selection toggle group lets each item keep its own pressed state.
Examples:
- Bold, italic, and underline formatting.
- Several category filters.
- Layer or annotation visibility controls.
- Independent display options in an editor.
Users should be able to predict whether zero, one, or several items may be active. Do not make a multiple-selection group look indistinguishable from an exclusive segmented control.
If the choices will be submitted as form values, checkboxes may communicate the model more clearly and work more naturally with form validation.
When to Use a Toggle Group
Use a toggle group when:
- The choices are closely related.
- The set is small enough to remain visible without wrapping unpredictably.
- Current selection affects the present tool, view, or result set.
- Users benefit from seeing all options at once.
- The pressed state can be made unmistakable.
- The single or multiple selection model is easy to explain.
Toggle groups work well in toolbars because the choices are frequent, compact, and contextual.
When Not to Use a Toggle Group
Avoid a toggle group when:
- Each item triggers a one-time command such as Save, Export, or Delete.
- The choice belongs to a conventional form field.
- There are too many options to scan comfortably.
- Option labels are long and create a crowded or unstable layout.
- Each choice opens a different content panel.
- A setting should be represented as an immediate on/off switch.
- Users cannot tell whether the items allow one or multiple selections.
For a large option set, a select, combobox, search, or filter panel may be easier to navigate.
Accessibility: Communicate the Group and Each State
Use native <button> elements for toggle buttons whenever possible. Native buttons provide keyboard activation and established semantics.
Each stateful button should expose its current state with aria-pressed:
<div role="group" aria-label="Text formatting">
<button type="button" aria-pressed="true">Bold</button>
<button type="button" aria-pressed="false">Italic</button>
<button type="button" aria-pressed="false">Underline</button>
</div>
The group needs an accessible name when its purpose is not already clear from nearby labeled content. A visible heading referenced with aria-labelledby is often better than an invisible label because every user receives the same context.
Keep toggle labels stable while aria-pressed communicates the state. For example, keep the label "Bold" in both states rather than changing it to "Remove bold."
Icon-Only Items
Icon-only toggle buttons need accessible names:
<div role="group" aria-label="Text alignment">
<button type="button" aria-label="Align left" aria-pressed="true">
<!-- left-align icon -->
</button>
<button type="button" aria-label="Align center" aria-pressed="false">
<!-- center-align icon -->
</button>
</div>
Use familiar icons, but do not assume every icon is self-explanatory. A visible tooltip can help sighted users, while the accessible name supports assistive technology.
Keyboard Interaction
Every toggle must be operable with a keyboard and have a visible focus indicator.
Standard buttons can remain separate Tab stops. In a dense application toolbar, a design system may implement composite keyboard behavior so users enter the toolbar once and move among controls with arrow keys. If you use that pattern, implement focus management consistently and test it with the rest of the toolbar.
Do not add arrow-key behavior only to imitate a visual segmented control. The keyboard model should match the component's semantics and the conventions of the surrounding interface.
Visual Design Rules
1. Make Selection Obvious
Pressed and unpressed states should differ with more than a subtle color shift. Combine cues such as:
- Background and border.
- Icon fill or weight.
- A checkmark or active indicator.
- Text weight and contrast.
Do not rely on color alone.
2. Keep the Layout Stable
Changing state should not resize a button or shift neighboring items. Reserve enough space for borders, icons, and labels in every state.
3. Show Group Boundaries Without Creating Ambiguity
Connected borders can communicate that controls belong together, but separation must remain visible. Users still need to identify each button, its label, and its focus state.
4. Preserve Comfortable Targets
Compact controls still need enough padding and separation for accurate pointer and touch input. Do not shrink icon buttons until their visible symbol becomes the only clickable area.
5. Plan for Narrow Screens
Wrapping a segmented control across two lines can break its visual model. For narrow layouts, consider shorter labels, a responsive alternative, or horizontal scrolling with clear affordance.
Example: View Selector
For a grid/list view selector, one view is always active:
<div role="group" aria-label="Results view">
<button type="button" aria-pressed="true">Grid</button>
<button type="button" aria-pressed="false">List</button>
</div>
Recommended behavior:
- The current view is selected on initial render.
- Activating the other item updates the results.
- Activating the already selected item does not create an invalid view with nothing selected.
- Focus remains on the control that was activated.
- The result layout changes without losing the user's position or active filters.
If changing the view causes a delay, communicate loading or completion near the results.
Implementation Checklist
Common Mistakes
Allowing an Invalid Empty State
If the product must always display grid or list view, users should not be able to clear the selected view.
Hiding the Selection Model
If users cannot predict whether choosing a new item will replace or add to the current selection, the group is not communicating its behavior.
Styling Buttons Without Exposing State
An .active class may change appearance, but it does not communicate pressed state to assistive technology. Expose the state semantically as well.
Using a Toggle Group for Navigation
If each item changes the current page or content panel, use navigation or tabs with the appropriate semantics.
Forgetting Responsive Behavior
A carefully connected desktop control can become a confusing two-row cluster on mobile. Test real labels at the smallest supported width.
Related UIXHERO References
- Parent hub: UI Components
- Foundation: Toggle Button UI
- Related principle: Progressive Disclosure
FAQ
What is a toggle group in UI?
A toggle group is a set of related toggle buttons that manages one active choice or several independent active choices. Common examples include view selectors, text formatting controls, and compact filters.
Can a toggle group allow multiple selections?
Yes. A multiple-selection toggle group allows several items to remain pressed, such as Bold, Italic, and Underline. The interface should make this model clear.
What is the difference between a toggle group and a radio group?
A toggle group usually controls contextual tool or view state. A radio group usually represents one value in a form. If users are answering a labeled form question, radio buttons are often the clearer choice.
Should toggle group items use aria-pressed?
Stateful toggle buttons should expose their pressed state with aria-pressed. Use native buttons where possible, and give the group and icon-only items meaningful accessible names.