Toggle is the name of a kind of switch, usually a button or key, that has two positions — on and off. It’s used to change settings or programs — the way you might toggle back and forth between screens as you video chat with two friends at once. The word has been around since the 18th century — in fact, it originally meant “a pin passed through the eye of a rope to fasten it.”

Today, toggles can be found everywhere from the keyboard’s Caps Lock and Num Lock keys to menu items within an app. They’re particularly common when providing users with options and preferences. When a toggle is pressed it changes from on to off, and when the user presses it again, the setting returns to its default state.

Ideally, toggles should be clear about what they’re doing and deliver an immediate result. They should have direct labels, use standard visual design, and be consistent across the application.

But there are times when using a toggle isn’t optimal. For example, if a toggle is pressed repeatedly by the same user (in an attempt to get the same result), it can confuse them. To avoid this, toggles should be used sparingly, and only when the current state of a feature is a clear choice for all users.

In these cases, we recommend using a radio button or checkbox instead of a toggle. These types of controls require less user cognitive effort, and they don’t rely on color to convey meaning. Moreover, a radio button or checkbox also follows WCAG 1.4.1, which states that the “input element’s value must be made explicit through appropriate labeling, and the input element’s default values must be shown”.

Toggles can be useful when implementing features with dynamic configuration. For example, a Champagne Brunch (or Canary Release) experiment may require that all users see the same behavior but some should be sent down one code path while others are routed down another. A Toggle can be useful to manage this by exposing the toggle in the same manner as other feature flags but making the decision at runtime rather than at deploy time.

In this case, the toggle configuration can be hardcoded in the source code using a preprocessor’s #ifdef feature or through commenting (which can allow for some flexibility but doesn’t let us re-configure a toggle in the future). We recommend this method for toggles that aren’t expected to re-configure frequently and only for use with very specific cohorts of users. For more dynamic toggles, a better option is to use a feature flag management tool such as Permission Toggle or Ops Toggle. These tools are designed to provide dynamic re-configuration of toggles and can be easily integrated with an existing source control system such as Git or Bitbucket.