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

Radio Group

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

Overview

• The Radio Group component is a form control for selecting one option from a set of choices.
• It displays a vertical list of radio buttons where only one can be selected at a time.
• The component is useful for clear, mutually exclusive decisions such as shipping methods or payment types.
• Each option in the group is defined as a radio button element with its own value and label.

...

• authorizationDisable – Specifies a policy set that determines when the component should be disabled based on user permissions. For example, setting to "readOnlyPolicy" will disable the radio group for users who don't have edit permissions according to the specified policy.

Guidelines

• Group radio options under a clear section title when appropriate.
• Maintain a logical, predictable order of options.
• Ensure each radio button has a concise, clear label (1–2 words, sentence-style capitalization, no colons).
• Provide consistent spacing: 24px around the form and 8px between radio options.
• Use sublines to separate different input groups if necessary.
• Keep interaction consistent — avoid forcing users to switch input methods frequently.
• Disclose additional radio options or groups only as they become relevant.

Accessibility

Usage

• Use when a single, mutually exclusive choice is required; define options in elements with a unique value.
• Preselect the most common/safe choice with defaultValue to reduce effort and avoid empty submissions.
• Preserve the user’s last pick across sessions by enabling saveInLocalStorage.
• Present read-only summaries (e.g., review steps) by setting the group to readonly: true.
• Keep temporarily unavailable choices visible but inactive by setting the specific option’s disabled: true.
• Ensure the selected value is submitted correctly by setting dataField and, if needed, choose where it goes with controlsRequestType (BODY, HEADER, or PATH).

Sizing & Layout

• Order options intentionally in elements; the group renders as a vertical list by design.
• Keep labels concise within each option’s displayValue to prevent wrapping in tight layouts.

States & Feedback

• Initial state: select a radio via defaultValue; communicate a preselected state clearly in displayValue.
• Read-only state: lock interaction with readonly: true while still showing the current selection.
• Option-level unavailability: set that option’s disabled: true so it remains visible but not selectable.
• Runtime visibility of the whole group: toggle hidden to show/hide while preserving form structure.
• Respond to user input immediately using events.ON_VALUE_CHANGE (for example, update this component’s own readonly or option disabled states).

Visibility & Authorization

• Disable interaction based on permissions with authorizationDisable (selection is shown but not changeable).
• Use hidden to conditionally remove the control from view while retaining its form presence when necessary.
• Prefer option-level disabled over removing options from elements so users understand availability.

Content & Localization

• Localize every option label using displayValue (for example, {"en-US":"Standard","de-DE":"Standard"}).
• Keep authoring-only names distinct with displayName; avoid using it for user-visible labels.
• Use short, concrete phrases in displayValue (1–2 words when possible) for scannability in vertical lists.

Dos & Don’ts

Accessibility

• Provide localized, announceable labels using elements[].displayValue.
• Choose the appropriate non-interactive state for clarity: readonly (show current selection without allowing change) vs elements[].disabled (show unselectable options).
• Use hidden to remove irrelevant controls from user view to reduce cognitive load while preserving form structure.
• When permission-based disabling is required, rely on authorizationDisable so users understand the control is intentionally non-editable.
• Avoid color-only meaning; communicate states through the built-in disabled/readonly and the wording in displayValue.
• Prefer elements[].disabled over removing options from elements so assistive technologies can convey that an option exists but is unavailable.
• Keep labels short and concrete in displayValue to improve announcement clarity in long lists.[NO DATA AVAILABLE]