Versions Compared

Old Version 1

changes.mady.by.user GE-DevDoc-Bot

Saved on

compared with

New Version 2

changes.mady.by.user GE-DevDoc-Bot

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

(this page was created automatically. In case of formatting issues, please visit the official Wiki Page)

Toggle Switch

Link to Figma: https://www.figma.com/design/yck1tcUXgdQ5aYX6iUAwrO/GE---Astronaut-Design-System?node-id=11600-78630&t=ftfrOGkPzlG2GaTo-1

Overview

  • The Toggle Switch Component is a form control that offers a simple on/off choice.
  • It is used for boolean settings such as enabling or disabling features.
  • The switch provides clear visual feedback compared to checkboxes.
  • It saves space compared to radio buttons for binary options.

...

  • authorizationDisable – Specifies a policy set that determines when the component should be disabled based on user permissions. For example, setting to "adminOnlyEditPolicy" will disable the toggle for non-admin users while allowing admins to change its state.

Guidelines

Usage

  • Always design the toggle for fast and intuitive input with minimal clicks.
  • Ensure high contrast between on/off states so users with low vision or in noisy/low-light environments can distinguish states.
  • Do not rely on color alone to indicate state; include position and clear visual feedback.
  • Support color-blind users by ensuring on/off states are distinguishable without red/green dependency.
    • Maintain consistency across themes (Daylight/Nightshift) so toggles remain recognizable
  • .
  • Use for binary, immediate preferences or feature flags; set intent with value and a distinct reset via defaultValue.
  • Persist preference-style choices across sessions by enabling saveInLocalStorage.
  • Remove from view when not applicable using hidden (remains part of the form data if needed).
  • Communicate permission limits without removing context by disabling via authorizationDisable; optionally present as readonly when edits aren’t allowed.

Sizing & Layout

  • Keep the surface tidy by conditionally removing the control with hidden rather than leaving inert space.
  • Make form resets predictable by setting defaultValue separately from the current value.

States & Feedback

  • Express non-interactive states with disabled or readonly (shows state, prevents changes).
  • Reflect the current on/off state with value; run dependent logic on change via ON_VALUE_CHANGE.
  • Persist user changes for preferences with saveInLocalStorage.

Visibility & Authorization

  • Hide when the setting must not be shown or is irrelevant (hidden: true).
  • Disable when discoverability matters but edits are blocked (authorizationDisable with disabled or readonly).

Dos & Don’ts

DoDon’t
Set a safe initial value and a distinct defaultValue for resets.Reuse one value for both current and reset, causing unexpected form state after reset.
Enable saveInLocalStorage for persistent preferences.Force users to reconfigure the same preference every session.
Use hidden to remove irrelevant controls from view and reading order.Leave a visible but meaningless control on screen.
Prefer authorizationDisable + disabled/readonly to show blocked settings.Hide controls that users should be aware exist but cannot change.
Submit with a clear dataField and correct controlsRequestType.Send the boolean in the wrong channel (e.g., header instead of body).
Handle changes immediately with ON_VALUE_CHANGE.Defer processing until an unrelated action.
Initialize logic and visibility on mount with ON_INIT (or user mode with ON_INIT_BASED_ON_USER_VIEW).Wait for the first user interaction to set up state.
Expose a stable test hook via dataTestId.Depend on brittle selectors tied to DOM structure.
Clean up listeners/timers with ON_DESTROY.Leave background work running after navigation.

Accessibility

  • Ensure the toggle switch is keyboard accessible (can be focused and toggled using standard keys such as Tab and Space/Enter).
  • Provide clear labels that describe what the toggle controls; avoid relying only on its visual state.
  • Use ARIA roles and states (e.g., role="switch", aria-checked="true/false"`) to make the toggle state available to screen readers.
  • Guarantee sufficient color contrast between on/off states to meet WCAG standards.
  • Avoid using only color cues; include position change or iconography to reinforce state.