Switch Component: Checkbox

Pattern Details

<!-- Version: [type="checkbox"] styled to look like a switch -->
<label class="check-switch" for="switch_1">
  Example Text 1:
  <input id="switch_1" type="checkbox">
  <span aria-hidden="true"></span>
</label>

<!-- Version: [type="checkbox"][role="switch"] -->
<label class="check-switch" for="switch_2">
  Example Text 2:
  <input id="switch_2" data-check-switch="" role="switch" type="checkbox">
  <span aria-hidden="true"></span>
</label>

<!-- Version: [type="checkbox"][role="switch"] - Alternate Markup/Style -->
<div class="switchbox">
  <label for="switchbox">
    Example Text 3:
  </label>
  <input id="switchbox" data-check-switch="" role="switch" type="checkbox">
</div>

Similar to the styled checkbox pattern, an input type=checkbox can be used to create a custom switch control. A switch and checkbox behave similarly.

As the ARIA specification notes:

A switch provides approximately the same functionality as a checkbox and toggle button, but makes it possible for assistive technologies to present the widget in a fashion consistent with its on-screen appearance.

That said, a switch can often be found in "settings" UI, where toggling the switch's state can immediately cause a function or state change to occur. A checkboxes are commonly used (have a very long history) within forms – where toggling its state is not expected to result in an immediate function until the form itself is submitted. That's not to say that toggling checkboxes cannot also be used to cause an immediate action to occur. For instance, using checkboxes as controls to filter search results on an e-commerce site. But, this is not an "official" difference between the controls – more just me trying to point to common use to indicate a reason as to why the heck we'd need two toggle controls aside from aesthetic reasons...

That all said, if implementing visually styled switches within your project, their implementation should be consistent across instances. Meaning that if a checkbox is visually designed to look like a switch (but continued to be announced as a checkbox), then there should be no instances where the same design is used for a role="switch". This would create confusion in why two similar looking controls are announced differently (for sighted users who also may use screen readers), or perform actions immediately or delayed until form submission.

The JavaScript

There is little JavaScript that is needed for this component, but what is there is largely for progressive enhancement purposes.

Using the data-check-switch attribute as a hook, an input with this attribute will receive a role="switch" when the script runs. Without JavaScript, it will announce itself as a checkbox.

The script also allows for the Enter key to be used to toggle the state of the switch, as checkboxes would otherwise only allow for the Space key to toggle their state.

Affects on Screen Reader Announcements?

Giving the input type="checkbox" a role="switch" announces the form control as a "switch", "toggle button" or continues to announce the control as a "checkbox" depending on the screen reader and platform in question.

The following is a break down of how this is handled by modern browsers and screen reader pairings.

Firefox 88.0.1

With VoiceOver on macOS 11.2.3: announces "switch" role and initial state. Activating the switch will produce a "clicking" noise, but no "on" or "off" announcement is explicitly made.

With NVDA 2020.4: announces "checkbox" role and initial state. Activating the 'switch' will announce the new state ("checked" or "not checked").

With JAWS 2020: announces "switch" role and initial state. Activating the switch will announce the new state ("on" or "off").

With TalkBack Android 11: announces "switch" role and initial state. Activating the switch will produce a sound effect, and the new state ("checked", "not checked") will be announced, oddly followed by a "loading" announcement.

Chrome / Edge 90

With VoiceOver on macOS 11.2.3: announces "switch" role and initial state. Activating the switch will produce a "clicking" noise and the new state ("on" or "off") will be announced.

With NVDA 2020.4: announces "checkbox" role and initial state. Activating the 'switch' will announce the new state ("checked" or "not checked").

With JAWS 2020: announces "switch" role and initial state. Activating the switch will announce the new state ("on" or "off"). When switching to the "on" state, JAWS will announce "pressed on". JAWS does not announce "pressed" when changing to the "off" state.

With TalkBack Android 11: announces "switch" role and initial state. Activating the switch will produce a sound effect, and the new state ("checked", "not checked") will be announced.

Edge 90

With Narrator: announces "switch" role and initial state. Activating the switch will announce the new state ("on" or "off"), along with a repeat of the switch's accessible name.

Safari

With VoiceOver on macOS 11.2.3 (Safari 14.0.3): announces "switch" role and initial state. Activating the switch will produce a "clicking" noise and the new state ("on" or "off") will be announced, along with a repeat of the switch's accessible name.

With VoiceOver on iOS 14.4.2: announces as "checkbox" role and initial state. Activating will produce a "clicking" noise and the new state ("checked" or "unchecked") will be announced.

Usage note:

Things have improved with switches since my initial testing of this role back in 2018, where state announcements were quirky if not missing all together (archived testing results below). NVDA and iOS Safari/VoiceOver are the hold outs on respecting the switch role, but at least these announce the switch as a checkbox with proper states.

Continue Reading

For an alternate minimal pattern to create switch checkboxes, and support for intermediate state, check out Adrian Roselli's Togglish Checkboxen CodePen, and his much longer write-up Under Engineered toggles.