How can I make a custom switch communicate its on and off state?

Start by identifying what the control changes. Use a switch when the setting has exactly two values, on and off. Its accessible name identifies the setting; its state communicates whether it is on or off. Keep the name stable as the state changes. [S1]

For example, the name could be “Email notifications,” with the state reported separately as on or off. The name tells someone what the control is for; the state tells them its current value. Avoid making the name itself change from “Enable email notifications” to “Disable email notifications,” because that mixes the setting’s identity with its state. [S1]

Ask whether the user is turning one setting on or off. If those are exactly the two values, a switch can fit. If the user is choosing among several options, or selecting a value that is not an on/off state, use a control pattern whose meaning matches that choice instead. [S1]

For instance, “Email notifications: on/off” illustrates a binary setting. “Choose a display density: compact, comfortable, or spacious” illustrates a choice with several values, not a switch. These examples are a way to apply the distinction, not a prescription for a particular visual design. Before choosing a control, write down the setting and the values people can select; that makes it easier to spot when “on/off” would misrepresent the choice.

Yes. A checkbox and a toggle button can also represent binary input. Choose the semantics that fit the design and how users should understand the setting; a switch is not automatically the right choice just because the control looks like one. [S1]

For the switch pattern, Space toggles the switch, and Enter is optional. [S1] When reviewing your control, check that the communicated state matches the setting’s current value. The guidance describes the switch pattern; it does not establish how a particular implementation will behave in every environment. Treat that as something to verify in your own interface rather than assuming the pattern description proves your implementation works.

Use this checklist when reviewing the control:

1. Confirm the choice: Are the only values on and off? If not, choose a pattern that matches the choice. [S1]
2. Name the setting: Use a stable name that tells people what is controlled, such as “Email notifications.” [S1]
3. Separate name and state: Communicate the current value as on or off without changing the name to describe the opposite action. [S1]
4. Check consistency: Compare the state communicated by the control with the setting’s current value.
5. Check keyboard behavior: For a switch, Space toggles it; Enter may also toggle it. [S1]
6. Reconsider the pattern: A checkbox or toggle button may better fit how users should understand the binary input. [S1]

A short planning note can help keep the review concrete:

Setting: [setting name] Values: on / off Name stays: [setting name] Current state: [on or off] Keyboard check: Space toggles; Enter [also toggles / does not toggle]

This is a review aid, not a technical implementation. Confirm that the final control’s name and state describe the setting consistently.