Open UIOpen UI

Radio Button

Names

Introduction

(For a lengthier discussion, on which this page was based, please refer to the original radio button issue)

The research showed that different design systems treat radio buttons in one of two ways, i.e.:

  • as a standalone component, that could be hosted on a “radio button group” component;
  • as an invariably non-independent part of a “radio button group” component (just like <option> tags are dependent on <select> tags).

The two approaches seem very similar at first, but the former seems to indicate that single “radio buttons” could exist, to probably indicate a binary state (on or off). The latter, however, shifts the scope up to the “radio button group”, which, although nonexistent as an HTML element, is an important concept for the W3 specification:

“A document must not contain an input element whose radio button group contains only that element.”

-- W3 HTML Specification

Besides, the mere existence of both approaches made elaboration of a concept table rather difficult, because it was not always clear whether a concept should apply to the radio button or the radio group. In any case, this research shows that most concepts apply to the radio buttons, while only some apply to the groups, eg:

  • radio-button-group-orientation
  • required-group
  • disabled / readonly (for the whole group)
  • group-label

After the research there are still discussions to be made, where any help would be welcome.

Anatomy

  • radio-button-group
  • radio-button-group-label
  • checked-indicator
  • label
  • radio-button-group-required-indicator
  • error-message

Concepts

basic
disabled
checked
invalid
state concept on a Radio Button component in Ant Design.
basic
state concept on a Radio Button component in Ant Design.
disabled
state concept on a Radio Button component in Ant Design.
checked
state concept on a Radio Button component in Atlaskit.
basic
state concept on a Radio Button component in Atlaskit.
disabled
state concept on a Radio Button component in Atlaskit.
checked
state concept on a Radio Button component in Atlaskit.
invalid
state concept on a Radio Button component in Bootstrap.
basic
state concept on a Radio Button component in Bootstrap.
disabled
state concept on a Radio Button component in Bootstrap.
checked
state concept on a Radio Button component in Carbon Design System.
basic
state concept on a Radio Button component in Carbon Design System.
disabled
state concept on a Radio Button component in Carbon Design System.
checked
state concept on a Radio Button component in Evergreen.
basic
state concept on a Radio Button component in Evergreen.
disabled
state concept on a Radio Button component in Evergreen.
checked
state concept on a Radio Button component in UI Fabric.
basic
state concept on a Radio Button component in UI Fabric.
disabled
state concept on a Radio Button component in UI Fabric.
checked
state concept on a Radio Button component in FAST.
basic
state concept on a Radio Button component in FAST.
disabled
state concept on a Radio Button component in FAST.
checked
state concept on a Radio Button component in Lightning Design System.
basic
state concept on a Radio Button component in Lightning Design System.
disabled
state concept on a Radio Button component in Lightning Design System.
checked
state concept on a Radio Button component in Lightning Design System.
invalid
state concept on a Radio Button component in Material Components Web.
basic
state concept on a Radio Button component in Material Components Web.
disabled
state concept on a Radio Button component in Material Components Web.
checked

inline
stacked
radio-button-group-orientation concept on a Radio Button component in Ant Design.
inline
radio-button-group-orientation concept on a Radio Button component in Ant Design.
stacked
radio-button-group-orientation concept on a Radio Button component in Atlaskit.
stacked
radio-button-group-orientation concept on a Radio Button component in Bootstrap.
inline
radio-button-group-orientation concept on a Radio Button component in Bootstrap.
stacked
radio-button-group-orientation concept on a Radio Button component in Carbon Design System.
inline
radio-button-group-orientation concept on a Radio Button component in Carbon Design System.
stacked
radio-button-group-orientation concept on a Radio Button component in Evergreen.
stacked
radio-button-group-orientation concept on a Radio Button component in UI Fabric.
stacked
radio-button-group-orientation concept on a Radio Button component in FAST.
stacked
radio-button-group-orientation concept on a Radio Button component in FAST.
inline
radio-button-group-orientation concept on a Radio Button component in Lightning Design System.
stacked
radio-button-group-orientation concept on a Radio Button component in Material Components Web.
stacked

default
button
solid-button
with-images
with-icons
style concept on a Radio Button component in Ant Design.
default
style concept on a Radio Button component in Ant Design.
button
style concept on a Radio Button component in Ant Design.
solid-button
style concept on a Radio Button component in Atlaskit.
default
style concept on a Radio Button component in Carbon Design System.
default
style concept on a Radio Button component in UI Fabric.
default
style concept on a Radio Button component in UI Fabric.
with-images
style concept on a Radio Button component in UI Fabric.
with-icons
style concept on a Radio Button component in FAST.
default
style concept on a Radio Button component in Lightning Design System.
button

big
medium
small
button-size concept on a Radio Button component in Ant Design.
big
button-size concept on a Radio Button component in Ant Design.
medium
button-size concept on a Radio Button component in Ant Design.
small

required-group concept on a Radio Button component in Atlaskit.
required
required-group concept on a Radio Button component in UI Fabric.
required
required-group concept on a Radio Button component in Lightning Design System.
required

without-labels
left-labeled
label-position concept on a Radio Button component in Bootstrap.
without-labels
label-position concept on a Radio Button component in Carbon Design System.
left-labeled
label-position concept on a Radio Button component in Lightning Design System.
left-labeled

medium
big
size concept on a Radio Button component in Evergreen.
medium
size concept on a Radio Button component in Evergreen.
big

left-to-right
right-to-left
direction concept on a Radio Button component in Lightning Design System.
left-to-right
direction concept on a Radio Button component in Lightning Design System.
right-to-left

Discussion

At a point during the research, the scope of this study os shifted from the “radio button” to the “radio button group”, because there is no particular strong use case for a standalone “radio button”, and also because this use case is against the W3 Specification, the actual component to be considered is the “radio button group”, being composed of two or more radio buttons.

Also based on this fact and on the current state of the design systems, a more final anatomy was proposed.

Proposed Anatomy - by Tag Hierarchy

This section shows the proposed visual constituents for the Radio Button Group, which is here considered to be the actual component, while the radio buttons are a part of the group.

  • Radio Button Group (the actual component)
    • Group Label (functions as a label for the whole group)
    • Required Indicator
    • Radio Button (at least two required)
      • Checked Indicator (input)
      • Label (optional)
    • Radio Button
      • and so on...
    • and so on...

The problem

The above anatomy is regular enough to be assembled in a way similar to (but more complex than) a <select>. Attributes set on the group would allow the developer to set the whole group as "disabled", "readonly", vertically or horizontally laid out, types of display (like buttons, radio buttons, combobox, etc), and attributes set on the radio buttons would set their specific states, as we do with <option> tags. It is important to understand that the function of radio buttons is almost the same as a <select> tag, and this is why the comparison makes sense.

However, by being so regular and requiring a specific HTML structure, we would lose structural flexibility. For this, here is another proposal.

Proposed Anatomy - by Attribute Binding

If the above proposal would accept other nodes as valid children, or at least a set of attributes that could replace some of the nodes (eg. an aria-label to replace the "Group Label"), the flexibility could be reestablished, by allowing the construction of more complex layouts, eg. semantic differential scales, such as:

An horizontal table with a question in a row and the answers in each of its columns

This could be achieved by combining table elements with radio button inputs and grouping attributes.

The problem

One could say it’s exactly the same behavior we have nowadays, because the radio buttons are bound together by the name attribute. However, the current structure still depends on a fieldset tag to visually group and label the collective of radio buttons, and this requirement prevents us from doing that exact table layout with actual tables, because we can’t use the fieldsets to group rows and put a legend inside it as well.

Today, the structure of such semantic differential scale could be represented like this:

QuestionAnswer 1Answer 2...
(table cell)(input name=1)(label)(input name=1)(label)...
(table cell)(input name=2)(label)(input name=2)(label)...

Each field has its label (or could have an aria-label), but the group itself has no formal label. This could be solved by having a way of binding a label to a group by using attributes, like this:

QuestionAnswer 1Answer 2...
(groupLabel labels=1)(input name=1)(label)(input name=1)(label)...
(groupLabel labels=1)(input name=2)(label)(input name=2)(label)...

The above case creates a new tag (or an unsemantic tag with a new aria-attribute) that labels the whole group by referring to its name.

Another alternative would be:

QuestionAnswer 1Answer 2...
(input name=1)(option group=1)(option group=1)...
(input name=1)(option group=3)(option group=2)...

In this case the label is the actual input, and it could have an appearance of a simple text. The answers, on the othter hand, could be an alternative use for the <option> tag, with an attribute to reference the name of the input. Selecting an option would change the value of the input.

To be discussed

The two main approaches presented above should be analysed in order to decide

  • In the first case:
    • whether the first, more rigid proposal should be developed;
    • or maybe even create an attribute to the <select> tag that would make it behave visually like radio buttons
  • Or, in the second case, strive for flexibility and:
    • propose modifications to the labeling of the current radio buttons;
    • or change the tags used to create them, like in the last example.