Checks & switches

Booleans in the control voice. By default that voice is ink, like the fields: black on white, white on black — a checked box fills with the mode's ink and the glyph is the ground. The palette is a user choice: blue re-voices field focus and checked fills with the accent, and that is the whole surface a palette touches — selection, primary actions and the focus ring keep the accent in every palette.

Write

<label class="form-check" for="f-members">
  <input id="f-members" type="checkbox" class="form-check-input" />
  <span class="form-check-label">Members only</span>
</label>

A switch is the same input wearing form-switch on the wrapper and role="switch" — the affordance carried entirely by presentation, which is exactly where an affordance belongs.

What the skin does

• Checked fills with the control voice — ink by default (the glyph is the ground colour), the accent under the blue palette (the glyph stays white).
• Sets sit in mk-check-group, and the bare class gives each control its system default: checkboxes stack; radios lay inline — a radio set is short by doctrine, so it earns one line. --stacked and --inline force either arrangement; writing one is the documented exception.
• Focus is the same ring every other control wears.
• Labels speak at control size; the small class is a no-op.

Which affordance

The Toggle field family argues this from the content side — what a stored boolean means. The control side is the same taxonomy:

Pick by what the sentence sounds like, not by what the last surface used.

Don't

• No hand-rolled check glyphs for plain booleans — the input is the control. (Menus draw their own check because a menuitemradio row is not an input; that one belongs to Menus.)
• No colour on unchecked states — absence is not a state worth announcing.