Checkboxes, Radios & Switches

## Three controls, three questions **Selection controls** let people pick from options without typing. Checkboxes, radio buttons and switches look similar and are often swapped carelessly, but each encodes a different answer to three questions: how many options can be true at once, whether the choice takes effect immediately or on submit, and whether 'none' is an allowed answer. | Control | How many can be on | When it takes effect | States | Hotel booking example | |---|---|---|---|---| | **Checkbox** | Any number, each independent | Usually on submit | Checked, unchecked, optionally mixed | Amenity filters; 'Add breakfast'; accepting the cancellation policy | | **Radio group** | Exactly one | Usually on submit | One checked, the rest unchecked | Room type: Standard, Deluxe, Suite | | **Switch** | One setting, on or off | Immediately | On, off (no middle state) | 'Email me price-drop alerts' on the account page | ## Checkbox - Each checkbox is an **independent** yes/no. Checking 'Pool' says nothing about 'Parking'. - A **single** checkbox fits a yes/no question whose unchecked state is a meaningful answer, such as opting in to a newsletter or accepting a policy. - Checkboxes are answers in a form: the choice is recorded now and acted on when the form is sent, which is why they sit comfortably above a submit action. - A parent checkbox can summarise a group with a **mixed** state when some children are checked. ## Radio group - Exactly **one** option is chosen from a set that is mutually exclusive, like room types. - All options are visible at once, so people compare them without opening anything. With many options, a select is often the better component. - Once a radio is chosen, clicking it again does not clear it. If 'none' is a real answer, add an explicit option such as 'No preference'. - Whether to pre-select a default is a judgement: a sensible default saves effort, but pre-selecting a paid upgrade nudges people into spending, and pre-selecting anything hides the fact that a choice was made. ## Switch - A switch is a physical metaphor: flipping it acts **now**, like a light switch. The Authoring Practices define it as a binary on/off input. - It has no middle state; WAI-ARIA 1.2 treats a mixed value on a switch as off. - Its label names the setting and **must not change** with the state; 'Price-drop alerts' stays the same while the state reads on or off. A label that flips to 'Alerts off' leaves people unsure whether it describes the current state or the action. - A switch inside a form that still needs a Save button is a classic mismatch: people flip it, leave, and lose the change. ## A decision sequence 1. Can more than one option be true at the same time? Use **checkboxes**. 2. Must exactly one of a few options be chosen? Use a **radio group**, and add 'No preference' if none is valid. 3. Is it a single setting that should take effect the moment it changes, with nothing to submit? Use a **switch**. 4. Is it a single yes/no answer in a form that will be submitted? Use a **single checkbox**. 5. Are there too many options to show at once? Consider a select or combobox instead. ## Immediate versus deferred effect The most expensive mistake is mixing the two models. A results page whose 'Free cancellation' filter is drawn as a switch but only applies after 'Show results' is pressed breaks the switch's promise. Either make it a checkbox in a filter panel with an explicit apply action, or make every change apply instantly and keep the switch. The component choice is a promise about timing; the behaviour has to keep it. ## Across platforms Native mobile platforms use the switch as their standard settings control and the web has the checkbox as its native binary input, so teams porting a design often carry one platform's habit into the other. A design system should define the controls by **semantics**, how many can be on and when the effect happens, and let each platform render them in its own idiom.