Checkbox, radio and switch

All three are the native <input> with a different look, and nothing else. The name, the value, the required and the screen reader announcement are still the browser's — the form posts the way it always has, and there is no JavaScript at all.

Examples

Everything below is the same <input> with different classes and attributes.

How to use

A class on the input and a <label class="tuc-choice"> around it. Clicking the text checks it, and the screen reader reads the text as the control's name — no for or id needed.

<label class="tuc-choice">
  <input type="checkbox" class="tuc-check" name="invoice"> Invoice by email
</label>

<fieldset class="tuc-choices">
  <legend>Shipping</legend>
  <label class="tuc-choice">
    <input type="radio" class="tuc-radio" name="shipping" value="standard" checked>
    <span>Standard <span class="tuc-choice__hint">Up to 7 business days</span></span>
  </label>
  <label class="tuc-choice">
    <input type="radio" class="tuc-radio" name="shipping" value="express">
    <span>Express <span class="tuc-choice__hint">Arrives tomorrow</span></span>
  </label>
</fieldset>

<label class="tuc-choice is-end">
  <input type="checkbox" role="switch" class="tuc-switch" name="notifications"> Email notifications
</label>

With a description, the text and .tuc-choice__hint go inside a <span>: that is what keeps the two stacked next to the control, aligned with the first line.

In a Django form

The class goes in the widget's attrs. For choices (RadioSelect, CheckboxSelectMultiple), loop over the field in the template: each item hands you the ready input in tag and the text in choice_label.

class PreferencesForm(forms.Form):
    invoice = forms.BooleanField(
        required=False, label="Invoice by email",
        widget=forms.CheckboxInput(attrs={"class": "tuc-check"}),
    )
    notifications = forms.BooleanField(
        required=False, label="Email notifications",
        widget=forms.CheckboxInput(attrs={"class": "tuc-switch", "role": "switch"}),
    )
    shipping = forms.ChoiceField(
        choices=[("standard", "Standard"), ("express", "Express")],
        widget=forms.RadioSelect(attrs={"class": "tuc-radio"}),
    )

<label class="tuc-choice">{{ form.invoice }} {{ form.invoice.label }}</label>

<label class="tuc-choice is-end">{{ form.notifications }} <span>{{ form.notifications.label }}</span></label>

<fieldset class="tuc-choices">
  <legend>{{ form.shipping.label }}</legend>
  {% for option in form.shipping %}
    <label class="tuc-choice">{{ option.tag }} {{ option.choice_label }}</label>
  {% endfor %}
</fieldset>

The POST is plain HTML: a checked box sends its value (or on, without one), an unchecked one sends nothing — which is why BooleanField needs required=False.

Mixed state

For the box that summarizes a group, like a table's "select all". It only exists as a property:

document.querySelector('#all').indeterminate = true;

Why they are drawn

accent-color would solve it in one line, but it hands you the system's look: on macOS a blue that is not yours, on Windows different corners, and neither with the radius of the rest of your fields.

And it only paints the checked box — the radio next to it would keep the system circle. Drawn, the three match each other and the neighboring input on any system, and use the same tokens: the accent is --tuc-accent, the focus ring is the fields' --tuc-accent-ring.

Keyboard and accessibility

It is all the browser's, because the control is still the input. The <fieldset> with <legend> gives the screen reader the name of the radio group.

With prefers-reduced-motion, the check and switch-slide transitions are turned off.

Classes

CSS only. There is no component to initialize and no custom event: listen to the native change.