Page History
...
- 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.
Links
- Figma: https://www.figma.com/design/yck1tcUXgdQ5aYX6iUAwrO/GE---Astronaut-Design-System?node-id=11600-78630&t=ftfrOGkPzlG2GaTo-1
- Live style guide: https://e1-dev.k8s.myapp.de/live-style-guide/id3/4-toggle
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
valueand a distinct reset viadefaultValue. - 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 asreadonlywhen edits aren’t allowed.
Sizing & Layout
- Keep the surface tidy by conditionally removing the control with
hiddenrather than leaving inert space. - Make form resets predictable by setting
defaultValueseparately from the currentvalue.
States & Feedback
- Express non-interactive states with
disabledorreadonly(shows state, prevents changes). - Reflect the current on/off state with
value; run dependent logic on change viaON_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 (
authorizationDisablewithdisabledorreadonly).
Dos & Don’ts
| Do | Don’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. |
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.