Switches and checkboxes are stylistic variants, not semantically different controls

[othermaciej]

The explainer argues that a switch is a semantically different control from a checkbox, citing style guides that suggest different usage. The style guides roughly suggest that switches should be used for actions with immediate effect, while checkboxes are used where an extra step like a Submit button is required.

At least on macOS and iOS (the operating systems that most brought these respective controls to respective prominence), this is not true.

macOS does not have a standard switch control and it is not seen in the default system UI or built-in apps (at least as far as I've seen; there may be exceptions). Checkboxes are often used for actions with immediate effect. In fact, this is the most common use. Preference dialogs on macOS are modeless and their controls are expected to have instant effect, without requiring an extra apply step. These dialogs often contain checkboxes.

iOS, on the other hand, does not have checkboxes as a standard control. (Exception: WebKit renders <input type=checkbox> as a checkbox on iOS largely for web compatibility reasons and legacy, e.g. switches are generally labeled on the opposite side from checkboxes but a checkbox element does not contain its label.) Switches are used for the same purpose as checkboxes on macOS. In fact, directly corresponding settings have a checkbox on iOS but a switch on macOS.

At least for these two platforms, checkbox and switch are stylistic variants of the same basic semantic. The idea that both always exist and mean different things is biased towards specific and fairly new platforms.

References: the macOS Human Interface Guidelines and iOS Human Interface Guidelines (not cited in the explainer, but probably should be). Note that the macOS version does not describe switches, and the iOS version does not describe checkboxes, because each has only one of these.

Because of this, I think the decision to make this a new element may be based on a faulty premise.

[othermaciej]

I guess I should add why I raise this concern. The web ought to be platform-independent to the extent as possible. Therefore introduction of concepts related to native platforms should involve a survey of all reasonably popular ones, not just the top 1 or 2 by installed base.

[GrosSacASac]

An input type=checkbox represents something that can be on or off. Similar to a switch. So they are semantically equivalent. Could we agree on this first ?

In the readme is written that the intent is different: Switch are used for more instant interactions: I think this is highly subjective. Even if research shows that it is true, would different intent mean different semantic ?

Maybe a switch is just a different visual representation over a checkbox. If that is the case it could potentially be solved by CSS.

For the goals in the readme

Easy and flexible customization

easy

Create an appearance macro

input[type=checkbox].switch {
    appearance: switch;
}

There is another open discussion about potentially exposing styling for title tooltips.
whatwg/html#4537
this could be done via shadow elements css selector for example.

Overall I suggest to make this proposal as small , atomic as possible. Adding the ability the fully customize the appearance seems out of scope, I mean it can be done in a follow up proposal.

[othermaciej]

Not sure why confused emoji. Is there a specific question, or should I just try to explain the points more concisely?

[cmmartti]

For an example of a robust toggle switch implemented in just CSS, see Under-Engineered Toggles. At more than 250 lines of CSS, it is by no means trivial, but certainly doable, and easily packagable into a library.

Notably,

If you want to build a native-like toggle in function as well as style, then you need to look at the ARIA switch role, understand that a switch affects an application immediately, explain this to a user in plain text, and recognize that not doing this correctly could be a Level A WCAG violation.

Is that enough reason to make a whole new switch element? I'm not sure, but it's the only way it would reliably match the appearance of the native OS switch, unless a new appearance: switch CSS rule was added to the spec.

[kleinfreund]

Checkbox and switch are not semantically equivalent.

They have different possible values:

• A checkbox has three possible states: checked (true), unchecked (false), mixed (Source: ARIA 1.1: checkbox)
• A switch has two possible states: on (true), off (false) (Source: ARIA 1.1: switch)

They have different semantics regarding the point in time at which the user commits to the changed value (e.g. it gets saved somehow).

• A switch’s value is processed in some fashion (e.g. saved) with changing state
• A checkboxes’s value is not processed when changing state (Source: en.wikipedia.org: Checkbox: Not actionable)

[domenic]

I think @othermaciej raises a fair point that on iOS and macOS they have historically been treated as stylistic variants. From what I understand that is changing; the recent WWWDC featured the introduction of NSSwitch to macOS, although I don't know many of the details, e.g. it doesn't seem to have impacted the human interface guidelines linked in the OP.

However, I think we have a pretty clear precedent on the web for switches being distinct. This comes in part from the accessibility tradition, as embodied by the ARIA specs and as discussed by @scottaohara in #15 (comment), as well as from the general patterns of web design systems, and web apps.

So I agree that (modulo recent macOS changes of which I don't know the details) people using web technologies to build macOS or iOS apps should follow the HIGs there. But my opinion is that on the web itself, there's an established important distinction in accessibility, functionality, and intent, beyond just the stylistic differences.

[othermaciej]

Some evidence has been presented that switch vs checkbox is a commonly accepted distinction either in general or on the web. I think much of that evidence suffers from platform bias, being based on either Windows or Material design or similar resources; in any case, none of it, even advice not specifically targeted at web design, seems to even mention the fact that macOS and iOS are different.

To address some specific examples:

[per ARIA], a checkbox has three possible states: checked (true), unchecked (false), mixed

Not really the case. Normal checkboxes will only cycle between the checked and unchecked states and will never expose mixes. A few rare checkboxes (both in native platforms and on the web) show the mixed/indeterminate state. But, while HTML has the ability to render the mixed state, it cannot expose a true tristate without additional script for state cycling. A tristate checkbox control arguably is more semantically different from a regular checkbox than a switch is.

Finally, the claim that checkboxes are naturally tristate is contrary to what the HTML Living Standard says: "The input element represents a two-state control that represents the element's checkedness state."

A checkboxes’s value is not processed when changing state (Source: en.wikipedia.org: Checkbox: Not actionable)

The Wikipedia article cites no references regarding macOS and seems to be written in total ignorance of it. macOS has had checkboxes with immediate effect since before most of the platforms used as examples existed.

From what I understand that is changing; the recent WWWDC featured the introduction of NSSwitch to macOS, although I don't know many of the details, e.g. it doesn't seem to have impacted the human interface guidelines linked in the OP.

Once the macOS Catalina public beta comes out, it will be possible for anyone to confirm whether any system UI has changed to stop using checkboxes that have immediate effect and has replaced them with switches. Anyone with access to the developer beta can check now.

It should also bee added that Cocoa has long offered stylistic variants of controls that are semantically equivalent, including toggle buttons that are like checkboxes or the new switches but which look different, and multiple variants of buttons.

But my opinion is that on the web itself, there's an established important distinction in accessibility, functionality, and intent, beyond just the stylistic differences.

I tried to do a cursory check of websites where checkboxes are present. It does seem that most checkboxes require a further step to have effect. Some of the most notable exceptions I could find are checkboxes in the ribbon on office.com documents and checkboxes found anywhere on iCloud.com,.

Switches seem to be rarely found except on Google web properties using material design (the only place I could find was accounts.google.com but I'd guess with more effort others could be found).

A much more common patter for instant-apply boolean states are toggle buttons, which change to a depressed state or otherwise change contents or appearance, but which contain their label (like the Subscribe button on YouTube, or the ubiquitous B/I/U rich text editing buttons).

Overall, it doesn't seem to be the case that the switch is the predominant instant-apply boolean control in practice on the web.

Finally, it should be noted that the HTML Living Standard does not specify that the semantics of <input type=checkbox> or any other type of input include delayed-apply treatment. Many types of controls can be either delayed or instant apply depending on context, including text fields.

Overall, it's not clear to me that this is representing a real de facto pattern in web design rather than platform bias plus third-party guides written with platform bias.

[stevefaulkner]

In the accessibility layer at least the semantics of switch are a distinct variant of the checkbox, in that the switch role represents a checkbox that has specific states on/off as compared to checkbox which has the more generic checked/unchecked. The 2 (checkbox/switch) are exposed in acc APIs: switch role mappings and checkbox role mappings. Perhaps @cookiecrook could provide some input as he proposed the addition of a distinct switch role in ARIA.

[Crissov]

<input type=checkbox> does, much like <input type=radio>, often come in groups. Check Boxes are the multiple-choice and Radio Buttons the single-choice (spatial) controls (true/false), similar to (linear) <select multiple> and <select>, which are frequently found in questionnaires.

Switches usually apply to a single boolean mode or option (on/off) that is independent from any others.
Depressable Toggles (down or lit = active) are quite similar to slideable Switches, but sometimes can be grouped (e. g. left/centered/right/justified horizontal text alignment), i. e. changing one of them affects the others, and usually they look a lot like <input type=button> with a textual or symbolic label on top unlike adjacent to it like many Switches have.

However, you will find instances of each of these that is used for the standard purpose of one of the other, since their semantics are in fact so similar. Therefore, I believe the differences only justify as much distinction as between <input type=search> and <input type=text>, hence introduce <input type=switch> and <input type=toggle> to HTML, which both fallback to <input type=checkbox> and only differ from it by their default appearance property value.

[othermaciej]

<input type=checkbox> does, much like <input type=radio>, often come in groups.

And they often stand alone too. For example, many login forms have a single "keep me logged in" checkbox.

Switches usually apply to a single boolean mode or option (on/off) that is independent from any others.

And they are often found in groups, too. This is especially apparent in iOS Settings (one of the first places to commonly use this control style) where you often see lists of related switches. Google account settings also have groups and switches.

Therefore, I believe the differences only justify as much distinction as between and , hence introduce and to HTML, which both fallback to and only differ from it by their default appearance property value.

I think the big challenge with this approach is that new input types fall back to <input type=text> in unaware browsers. If we could do the fallback you describe (which would be doable if checkbox had been an independent element in he first place) this would be a really neat solution.

[Crissov]

I'd argue that a standalone Checkbox can always be replaced by a Switch (or perhaps Toggle) without affecting semantics.

Instead of dedicated new types, we could use existing attributes that currently do not apply to type=checkbox. Here are some example ideas for that:

Groups and Mandates

• <input type=checkbox>:
  • default, independent, solitary checkbox
  • tick box ☐☑ for mouse/desktop
  • switch (slide) for touch/mobile
• <input type=checkbox name=foo>:
  • member of a checkbox group
  • ballot box ☐☒ or ☐■ or ☐▣ for mouse/desktop
  • toggle (press) for touch/mobile
  • ideally there was a declarative way to set a minimum and maximum number of checkable boxes within the group
• <input type=checkbox required>:
  • bi-state ☐☑ or tri-state box ▩☐☑
  • indeterminate initial state (unless set by checked or value) that cannot be returned to

Numeric Values

• <input type=checkbox multiple [min] [max] [step] [value]>:
  • like a + or add button where every activation increases value by step (default: 1) until max (default: 1) is reached, another activation overflows value to min (default: 0), which is also the initial state unless checked is set when it is 1 (or 0 + step)
  • never a toggle!
• <input type=checkbox [multiple] [min=0] [max=1]>:
  • default values for min and max
  • bi-state ☐☑
  • checked = value=1
• <input type=checkbox [multiple] min=-1 [max=1]>:
  • tri-state ▩☐■, Schrödinger's box
  • -1 = indeterminate
  • 0 = false/no/off/dead
  • 1 = true/yes/on/alive
• <input type=checkbox [multiple] [min=0] max=2>:
  • tri-state ☐☑☒ or ☐▣■ or ☐◪■ or ☐◨■ etc.
  • 0 = false/no/off/dead
  • 1 = probable/hm/transitioning/zombie
  • 2 = true/yes/on/alive
  • (3 = godmode)
• <input type=checkbox [multiple] min=-1 max=0>:
  • bi-state ▩☐ or ▩◪ or ▩◨
  • -1 = indeterminate
  • 0 = known but confidential or unavailable

Size

• <input type=checkbox [size=0]>:
  • bi-state
  • default value for size
  • tick box ☐☑ for mouse/desktop
  • switch for touch/mobile
• <input type=checkbox size=1>:
  • bi-state
  • ballot box ☐☒ for mouse/desktop
  • toggle for touch/mobile
• <input type=checkbox size=2>:
  • bi-state
  • toggle everywhere
• <input type=checkbox size=3>:
  • bi-state
  • switch everywhere
• <input type=checkbox size=-1>:
  • bi-state
  • ballot box ☐☒ everywhere
• <input type=checkbox size=-2>:
  • bi-state
  • tick box ☐☑ everywhere

[domenic]

Switches seem to be rarely found except on Google web properties using material design (the only place I could find was accounts.google.com but I'd guess with more effort others could be found).

A much more common patter for instant-apply boolean states are toggle buttons, which change to a depressed state or otherwise change contents or appearance, but which contain their label (like the Subscribe button on YouTube, or the ubiquitous B/I/U rich text editing buttons).

Overall, it doesn't seem to be the case that the switch is the predominant instant-apply boolean control in practice on the web.

We took this critique to heart and went to confirm that our intuition about the importance of switch was not limited to Material Design properties. Here are some examples we found on sites we use daily, plus some comments as to whether they appear to be stylistic or semantic decisions.

Microsoft Office 365 Outlook

Uses switches for things that instantly change, and checkboxes for things that need to be "Save"ed:

Facebook Messenger.com

Unclear what criteria they are using between switches and checkboxes. Both seem to apply instantly, and pressing Esc does not undo the choice. This may indeed be stylistic.

Facebook.com

Uses switches for settings which apply instantly, and checkboxes for things which you need to take further action to process.

app.starbucks.com

Uses switches for settings which apply instantly. Uses a checkbox for "remember me" on their sign-in screen.

cointracking.info

Uses switches for settings which apply instantly to the current data visualization.

yahoo.co.jp

Found a switch! @tkent-google can expand if needed.

kuronekoyamato.co.jp

Found a bunch of switches! @tkent-google can expand if needed.

[myakura]

yahoo.co.jp

this is a switch to enable personalized ads (the label translates as "enable tracking data for advertising and etc." or something like that).

kuronekoyamato.co.jp

this one is a bit awkward... the "switches" on the second column is to choose pickup between home and local business office. comparing to other ones these are just ill-designed radio buttons...

[tkent-google]

I don't oppose the opinion that switches are stylistic variants of checkboxes. However, switch should be implemented as a separated type because its UI is different from checkbox.

A switch widget typically have some UI parts such as a track and a thumb. We'd like to provide ability to customize each of them, and probably these parts will be exposed as pseudo elements or shadow parts. A checkbox doesn't have such parts. If switches and checkboxes were implemented as a single type., and UA would need to reconstruct shadow trees depending on switch-or-checkbox, and a DOM-level flag would be necessary to distinguish them, not a CSS property.
Also, I don't want to add new states to HTMLInputElement. It's already too complex and the source of serious bugs.