• Atom
  • CORE COMPONENT
  • Taxonomic name: A-RADIO
  • Added on: v3.0.0 (15/09/17)
  • Updated on: v5.6.1 (26/04/21)

Radio buttons

Return to component documentation

v5.6.1

Positioning for pictorial radio sprites has been updated.


v5.6.0

To improve page load and layout times, the additional attributes decoding, width and height must be set on all inline images. The decoding should be set as decoding="async">, while the width and height attributes should be set with the pixel size of the image to be loaded in; the browser will then allocate an appropriately-sized area ready for when the image is loaded, preventing the page layout from adjusting once the image is available.


v5.5.0

To aid screen reader users in completing forms without error and also with understanding and fixing any errors that have occured, some additional aria attributes are now recommended to be applied across all form fields/rows.

All form row help, explanatory text, form row instructions and form row errors must have a unique id assigned to them and be appropriately linked to either the individual form input or the form row using aria-describedby. This ensures that the help text is read out immediately on focus of the form input/fieldset. When there is more that one item that requires referencing within the aria-describedby attribute the id values must be supplied in the form of a space separated list. For example if there is an error with id of 'err1' and help text with id of 'help1' the value for the aria-describedby attribute would be 'err1 help1'.

All inline form error messages should now start with the hidden text 'Error: ' so that when read by out by a screen reader it is immediately clear that the text being read is an error message.

All erroring form fields (or fieldset if a group or radios/checkboxes) must have aria-invalid="true" set on them, ensuring that when a user focus' on an errored form field, the field will be announced as invalid, so the user is then aware that there in an issue that requires fixing.


v5.4.0

The background colour of a radio when placed onto any background apart from white has been updated from #f9f9f9 to #fff in order to maintain colour consistency between form elements.

The border colour for radios has been updated from #aaa to #737373 in order to meet the minimum contrast ratio of 3:1 for non-text elements.

Radio styling prior to v5.4.0

v5.3.0

The font size used for this component has been reduced from 20px to 16px following the darkening of the green used on forms so that it now passes WCAG AA contrast levels for standard sized text.

Radio using 20px font size in v5.2.0

v5.0.0

Aria role="radiogroup" removed from fieldset element as the role is already implied by the element itself.

A number of class names for the list of radios have changed to align with the form row group. Prior to v5, the markup was as follows:

Radios in a single column/stacked

<fieldset class="m-form-row">
	<legend class="a-label">...</legend>
	<div class="m-form-row__content">
		<ul class="m-radio-group">
			<li class="m-radio-group__item">
				<label class="a-radio" for="...">
					<input class="a-radio__input" type="radio" name="..." id="..." value="..." />
					<span class="a-radio__label"><span class="a-radio__label-inner">...</span></span>
					<span class="a-radio__ui"></span>
				</label>
			</li>
			...
		</ul>
	</div>
</fieldset>

Radios in two columns

<fieldset class="m-form-row">
	<legend class="a-label">...</legend>
	<div class="m-form-row__content">
		<ul class="m-radio-group m-radio-group--double-column">
			<li class="m-radio-group__item">
				<label class="a-radio" for="...">
					<input class="a-radio__input" type="radio" name="..." id="..." value="..." />
					<span class="a-radio__label"><span class="a-radio__label-inner">...</span></span>
					<span class="a-radio__ui"></span>
				</label>
			</li>
			...
		</ul>
	</div>
</fieldset>

Pictorial radios

<fieldset class="m-form-row">
	<legend class="a-label">...</legend>
	<div class="m-form-row__content">
		<ul class="m-radio-group m-radio-group--pictorial [ Modifier ]">
			<li class="m-radio-group__item">
				<label class="a-radio" for="...">
					<input class="a-radio__input" type="radio" name="..." id="..." value="..." />
					<span class="a-radio__label">
						<span class="a-radio__label-image">
							<img src="..." alt="" />
						</span>
						<span class="a-radio__label-inner">...</span>
					</span>
					<span class="a-radio__ui"></span>
				</label>
			</li>
			...
		</ul>
	</div>
</fieldset>

The class m-radio-group--double-column, which made radios sit in two columns at tablet and desktop, has been removed as a result of the move to using form row group. By default radios will now sit in two columns unless the new modifier class m-form-row-group--stacked is used to force the radios to sit in a single column or to stack.


v4.16.0

Following WCAG 2.1 criterion 1.4.3: Contrast (Minimum), font size increases have been made so that all large-scale text has a contrast ratio of at least 3:1.


v4.13.0

Segmented radio controls can again be used for 2-5 options for short character length selectable Boolean content.


v4.10.0

Pictorial radios are now only shown in two columns at desktop to prevent issues with text overflowing due to lack of space.


v4.2.0

Radio option was introduced; rationale for this change:

Problems

  • Research tends to show it's eaiser for users to answer form questions when the options are shown rather than hidden in a dropdown; there is a lower cognitive load to understanding the options available to answer the question and touch a button tends to be quicker on touch devices than selecting from a dropdown
  • There is a growing base of evidence that form completion rates tend to be higher in forms using stylised radio buttons compared to dropdowns
  • With the current segmented control pattern, we can only display up to 5 options before a dropdown needs to be used
  • Option labels tend to be more than 2 words and wrap very easily onto 3 or 4 lines. This makes the control harder to read and answer

Solution

  • The radio button pattern allows up to 8 options delaying need to use a dropdown
  • It can support longer labels with the single column stacked version
  • It continues to support shorter labels with the double column version

Differences between radio buttons and segmented control

  • The segmented control was originally designed to behave as a switch for yes/no/maybe answers. Being used for questions with longer label answers wasn't the original intent. This causes the wrapping issue and difficulties reading the answer
  • The radio buttons shall be used for questions that are not yes/no answers
  • Segemented control is now limited to only 3 options. Recommendation being for yes / no / maybe questions

v3.0.0

Component added.