Selection

v1.0

Selection helps users choose options or items, understand what is selected and when it takes effect, and revise their choices.

Overview

Use selection when users need to provide a value, change the current experience, or mark items for a later action. Make the available choices, allowed number of selections, current selection, and effect of the choice clear.

Selection covers the choice and its shared behavior. It does not cover navigation, temporary interaction states such as focus or press, text highlighting, or the complete workflows that build on a selection. See Interaction states for temporary and visual states, Filtering for refining results, and Bulk editing for actions performed on selected items.

Considerations

Understandable

Make it clear what's available to select and what's currently selected. Communicate when and how the choice takes effect.

Purposeful

Match the selection approach to the task and consequence. Avoid choosing for users, unless you have high confidence in the selection.

Predictable

Let users review and revise selections, and communicate when a context change makes a selection unavailable, incompatible, or invalid.

Choosing an approach

Start with the user’s need and how the selection should behave, then choose the appropriate component or pattern.

Commit a value

The choice becomes submitted, stored, or saved data.

User need	Selection behavior	Recommended approach
Choose one value from a set of options	One option stays selected until the form submits	Use radio buttons for four or fewer options when users need to see and compare them Use a dropdown or web-only select list for longer sets, limited space, or when direct comparison isn’t needed
Choose multiple independent values	Any number of options can be selected and submitted together	Use checkboxes
Make one yes-or-no choice in a form	The single binary choice submits with the form	Use a single checkbox
Choose an existing object as a value	An address, account, or other object becomes the answer	Treat the object as a single-choice option, using radio buttons, a dropdown, or another approved picker based on the number and complexity of the choices
Choose a date or bounded span	The value is a date, range, or bounded number	Use a date field or approved range input; follow Filtering when range refines results

Change the current experience

The choice changes a setting, persistent item state, section-level view, or result set.

User need	Selection behavior	Recommended approach
Turn a setting on or off	The setting changes immediately	Use a switch
Watch, save, like, or favorite an item	A persistent item state changes immediately	Use a toggled icon button
Change a section-level state, sort, or view	One of up to four mutually exclusive choices takes effect immediately	Use a segmented button for section-level choices, not navigation
Compare visually differentiated options	One or more choices change what's shown or available	Outside forms, use a toggle button group when stronger visual emphasis helps users compare options
Refine a result set	Selected criteria change which results appear, immediately or after explicit application	Follow Filtering

Mark items for a later action

Item selection marks existing items for a later action, while value selection uses the chosen item to answer a question or set a value.

User need	Selection behavior	Recommended approach
Mark one or more items for a later action	Items form a temporary selected set; count and scope stay visible even when selected items are out of view	Use checkboxes within a list row or table, then follow Bulk editing or the relevant task pattern

A menu is a presentation context, not a selection approach. See Menus for platform-specific presentation guidance.

Delete, Share, and Edit are actions, not selections. Don't treat them as selection controls.

Behavior

Selection behavior depends on how a choice starts, takes effect, and persists.

Starting state

When to pre-select values

Pre-select values only when they reflect saved data, a restored in-progress selection, or a strong, context-appropriate default that users can easily change. Do not preselect a value merely to remove a step or steer users toward a choice.

For selections involving consent, privacy, legal, financial, policy, or trust considerations, work with your Legal, Privacy, and Policy partners to determine if explicit user action is required.

Application and dismissal

Immediate application

Apply a choice immediately when the control represents an immediate state change and the component supports it.

Examples:

A switch changing a setting
A toggled icon button adding an item to Watchlist
A menu-based radio or checkbox updating a value

Explicit application

Use explicit application when users need to review multiple selections together, complete dependent information, or confirm a result that's hard to reverse.

Changes remain drafts until the user commits them. Cancelling discards the drafts and restores the previously applied state.

Don't present a draft selection as applied.

Examples:

Bulk deleting selected items
A date range where start and end dates both need to be set before the selection is meaningful
Editing preferences in a settings sheet where each toggle would trigger a separate save if applied immediately

Keep application separate from dismissal

Treat selection, application, and dismissal as separate steps. Keep the selection surface open while users review options, complete dependent fields, or confirm a consequential result.

A single-select menu, popover, or bottom sheet can close on selection when the choice is low-risk and easy to reverse, no further input is needed, and the component supports selection-triggered dismissal.

Keep multi-select and multi-step surfaces open while users make or review their choices. When the surface uses explicit application, provide a commit action before closing.

On web, arrow keys change the selection in form-based radio groups. Keep the containing surface open when users need to review other options.

Persistence and context changes

Keep selections while the task stays the same

Keep selections intact within a task when their meaning and scope haven't changed, including when sorting, paging, adapting layouts, or opening related content.

When selected items are outside the current view, show the total count, the scope, what the next action affects, and how to review or clear the full selection.

Keep temporary item selections within the current task. Persist them across tasks, sessions, or devices only when an explicit product requirement defines them as saved data or a remembered preference.

Respond when context changes

When a context change affects a selection's meaning, availability, or scope, don't silently retain an invalid selection or discard the user's work without explanation.

When the selection is	Behavior
Valid but no longer visible	Preserve the selection and continue communicating its total count and scope
Temporarily unavailable	Keep the selection identifiable, explain why it cannot currently be used, and provide a recovery path when possible
Incompatible or invalid	Do not continue presenting it as a valid applied selection; require users to resolve it or clearly communicate an appropriate automatic change
Removed or no longer exists	Remove it from the current selection, update any count or summary, and communicate what changed
Dependent value reset by a parent choice	Make the relationship and reset visible rather than allowing the previous value to disappear without feedback

Dependent content and system feedback

Don't nest interactions inside selection controls

When a selection reveals related fields, links, buttons, or actions:

Place dependent content next to the selection control, not inside it
Use layout and proximity to show the relationship
Don't put interactive controls inside a radio label, checkbox label, toggle button, or other selection control

Pending, success, and failure states

When an update is delayed, use the component's selected state to acknowledge the input and its pending or loading state to show that the update is in progress. Prevent repeat changes while it's pending.

On success, show the new applied state and update any related counts, summaries, or dependent content.

On failure, return to the last valid applied state, explain that the change didn't complete, and offer a retry when appropriate. Never show a state the system didn't apply.

Communicating selection

Clearly communicate a selection’s purpose, state, scope, and outcome.

Labels and terminology

Name the decision and choices

Use a group label or heading that identifies the category or decision users are making. Prefer a specific label such as Choose a payment method or Condition over a generic instruction such as Select an option.

Write option labels as noun phrases that describe the choice from the user's perspective. Keep labels grammatically parallel within a group.

Selected vs. applied vs. saved

Use these terms to distinguish where a choice is in its lifecycle. A value may be selected before it is applied, or applied immediately without becoming a saved preference.

Use	When
Selected	The option, value, state, or item is currently chosen in the UI
Applied	The selection affects data, results, settings, or the surrounding experience
Saved	The selection is stored and will persist beyond the current task or session

Values, counts, and scope

Show selection count and scope

When selected items may extend beyond the current view, show both count and scope. For example: 6 selected or All 126 items selected.

A count alone may be insufficient when users cannot tell whether it covers the current page, visible items, filtered results, or all items.

Follow Numerals for formatting.

Actions and feedback

Choose action labels by outcome

Use the Writing glossary as the source of truth when it defines a domain-specific action.

Label	Use when
Apply	Committing draft selections so they begin affecting the current experience
Save	Committing information that will remain beyond the current task or represents stored data
Done	Ending an interaction after its changes have already taken effect
Cancel	Discarding uncommitted changes and retaining the previously applied state
Clear	Removing the current selection and returning to no selection, when no selection is valid
Reset	Returning to the experience’s defined initial or default state
Deselect	Removing one option or item from the current selected set
Remove	Removing a directly represented object or applied value

Explain changed or failed selections

When a selection becomes unavailable, invalid, or removed, explain what changed, whether it remains applied, what users need to do next, and whether it can be restored.

Don't rely on a disabled appearance alone to communicate the change. When an update fails, explain that it didn't complete and offer recovery when available.

Avoid separate success feedback when the changed control state already communicates the result.

Localization

Don't build selection messages from separately translated fragments, and don't assume category, value, and count appear in the same order across languages. Use localized plurals and consistent terminology across responsive and platform-specific presentations.

Accessibility

Accessibility depends on the components and presentation. Review each component’s Accessibility guidance alongside this page. The Accessibility foundation defines shared outcomes; implementation varies by platform.

Use approved controls and semantics

Use approved Evo components so names, roles, values, and states are communicated accurately. Give each control a clear, visible name; name related groups when required; use supported semantics and visual states; and do not rely on color alone or recreate radio buttons, checkboxes, switches, or buttons through visual styling.

Preserve expected behavior and focus

Preserve each component’s documented interaction model across keyboard, screen reader, touch, and pointer use. Moving through or selecting options should not unexpectedly apply a consequential change, dismiss a surface, navigate away, or move focus.

When a supported single-select surface closes after selection, follow its documented dismissal and focus-restoration behavior. When selection reveals dependent content, keep reading, visual, and focus order aligned.

Communicate changes caused by selection

Make changes caused by selection available to assistive technology when they occur outside the selection control or may otherwise be missed. Examples include a filter updating a result count elsewhere on the page, a choice revealing dependent content, or a selection becoming invalid or changing scope.

When the control’s state communicates the complete outcome, additional feedback may not be needed.

Verify platform behavior

Keep selection intent and outcomes consistent across responsive web, iOS, and Android. Use approved platform components and conventions. Add platform guidance only when it affects a design decision and platform and Accessibility owners verify it.

Best practices

Use these examples to avoid selection behavior that makes choices difficult to understand, review, or operate.

Match the control to the number of choices

Do use radio buttons when only one option can remain selected, and checkboxes when users can select multiple independent options.

Two mobile filter sheets shown side by side: Condition uses checkboxes with Used and Not Specified selected, while Sort uses radio buttons with Ending Soonest selected.

Don’t use checkboxes for mutually exclusive choices or radio buttons when users need to select more than one option.

Two mobile filter sheets shown side by side: Condition uses radio buttons with Used selected, while Sort uses checkboxes with Ending Soonest and Newly Listed selected.

Communicate what has been selected

Do keep the selected value visible after the selection control closes.

Checkout screen where Pay with shows Visa ending in 1234 beside a Change action, above the order summary.

Don’t make users reopen the control to remember what they selected.

Checkout screen where Pay with shows only a Change action above the order summary, without identifying the selected payment method.