• Molecule
  • CORE COMPONENT
  • Taxonomic name: M-FORM-ROW-GROUP
  • Extension: FORMS-EXTENDED-A
  • Added on: v4.15.0 (08/11/19)
  • Updated on: v5.5.0 (23/03/21)

Form row group

Form row group allows pairs of linked form elements to sit side by side within forms, for example dropdowns or dates.


Design and usage

Structure

  • Keep 50/50 split where possible (max width device dependant - see 'Placement' below)
  • For components with fixed padding rules refer to recommended usage (e.g. prefix and suffix)
  • Side-by-side input fields require 15px horizontal padding between them.

Placement

  • Left aligned by default with relevant field positioned to the right 10px horizontal padding.
  • Can sit 50/50:

    • Desktop: 6 or 8 grid columns
    • Tablet: 7 grid columns
    • Mobile: 4 grid columns
  • For fixed padding inputs, retain internal pattern rules within column widths above.

Accessibility and screen readers

  • Focus must not be transferred automatically between the separate fields to maintain the accessibility and usability of the form
  • Aria-invalid must be used to indicate when an error has occurred with this element
  • Aria-describedby must be used to link any help, instructional and/or error text with the element/form fields

Use case and exception scenarios

  • Mobile: Will always stack
  • Inputs with fixed padding rules (eg. see 'form affix') contained within recommended columns indicated above.

Design anatomy

For usage within forms follow Form UI padding rules - see single page form template

Examples

Full width form components

Interactive example

Code example

<fieldset class="m-form-row [ Modifier ]">
	<legend class="a-label">...</legend>
	<div class="m-form-row__content">
		<ul class="m-form-row-group">
			<li class="m-form-row-group-item m-form-row-group-item--full-width">
				<!-- Visually hidden label if not present within form component -->
				<label class="m-form-row-group-item__label" for="...">...</label>
				<!-- Form component -->
			</li>
			<li class="m-form-row-group-item m-form-row-group-item--full-width">
				<!-- Visually hidden label if not present within form component -->
				<label class="m-form-row-group-item__label" for="...">...</label>
				<!-- Form component -->
			</li>
		</ul>
	</div>
</fieldset>

Columns form component

Interactive example

Code example

<fieldset class="m-form-row [ Modifier ]">
	<legend class="a-label">...</legend>
	<div class="m-form-row__content">
		<ul class="m-form-row-group m-form-row-group-items--1-small m-form-row-group-items--2-medium">
			<li class="m-form-row-group-item">
				<label class="m-form-row-group-item__label" for="...">...</label>
				<div class="m-form-affix">
					<div class="m-form-affix__label-wrapper">
						<!-- Form component -->
						<span class="m-form-affix__label" aria-hidden="true">st</span>
					</div>
				</div>
			</li>
			<li class="m-form-row-group-item">
				<label class="m-form-row-group-item__label" for="...">...</label>
				<div class="m-form-affix">
					<div class="m-form-affix__label-wrapper">
						<!-- Form component -->
						<span class="m-form-affix__label" aria-hidden="true">lbs</span>
					</div>
				</div>
			</li>
		</ul>
	</div>
</fieldset>

Checkbox and radio groups

For details on class usage when combining with groups of checkboxes or radios see the documentation for those components:

Development and test

Notes for developers

Form row groups must be contained within their own fieldset and the legend should have a label which accurately describes the purpose of both fields.

Ensure visually hidden labels have been created for each of the form elements within the molecule if not present.

Pairs of form fields should sit side by side with no intervening characters, images, etc.

Error states follow standard patterns; only one error message allowed per molecule / pair of form elements.

The following form elements can side sit by side in any combination, see documentation for each form element for further information and additional options:

The following form affix elements can side sit by side in any combination, see form affix documentation for further information and additional options:

  • Text boxes with prefix/suffix
  • Drop downs with prefix/suffix

Input types

Care should be taken when choosing input field types for various uses, particularly with regard to number entry, as making the wrong selection could prevent users from inputting the required details into a form. For further information, see the form introduction page.

When disabling form elements, do not solely rely on the is-disabled class, but ensure that the disabled attribute is also set on the relevant form element or input. If an entire set of form elements is to be disabled, the is-disabled class and disabled attribute should be added directly to the fieldset instead, and not to each individual element within it. However if only one element from the set is disabled, then the class and attribute should be applied to that element only.

Aria usage for errors and help text

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 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.

When linking help or errors, or even adding aria-invalid to the markup careful consideration must be taken as to where it is most appropriate to apply the value. The following rules should be used to decide where the attribute(s) should be applied.

  • Single form field - All attributes should be applied directly to that form field
  • Group of form fields but only one in error or help text applies to only one - Apply the attribute(s) to the only field in error or where the help text applies
  • Group of form field where all in error or the help text applies to all - Apply the attribute(s) to the groups surrounding fieldset (form row)

There may situations where more than one of these rules applies to the overall form row for example a date range where the instruction text applies to both fields so should be linked to the fieldset for the date range but one of the two fields is in error so the error should be linked to just that field not to the fieldset.

Important messages

To help those using assistive technologies, make sure that success/error messages which need to be announced to users have their aria attributes updated to role="alert" and/or aria-live="assertive".

Using autocomplete

Users appreciate when websites save them time by automatically filling common fields like names, email addresses and other frequently used fields, plus it helps to reduce potential input errors, especially on virtual keyboards and small devices.

Browsers use many methods to determine which fields they can auto-populate based on previously specified data by the user, and you can give hints to the browser by providing both the name attribute and the autocomplete attribute on each input element.

Further details can be found in the developer notes on the form introduction page.


Notes for testers

  • Follow regular testing rules for form elements used within the form row group.

Classes overview

The following table gives you a quick overview of the CSS classes that can be applied.

Class Outcome Required Applied to Comments
.m-form-row-group Base style wrapper for form row group Yes m-form-row__content > ul  
.m-form-row-group--option-group Styling for radio and checkbox groups to ensure vertical alignment   .m-form-row-group  
.m-form-row-group-items--size-breakpoint Modifier to place checkboxes in multiple columns for each breakpoints
size: from 1 to 6
breakpoint: small, medium, large
  .m-form-row-group  
.m-form-row-group--pictorial Styling for radio and checkbox groups to allow pictorial images   .m-form-row-group--option-group  
.m-form-row-group-item Wrapper styling for form elements Yes .m-form-row-group > li  
.m-form-row-group-item--full-width Modifer to force radios to be full width (not natural width) when not in column system &bnsp; .m-form-row-group-item Only exclude if using a group of standalone checkboxes
.m-form-row-group-item__label Hidden label class Yes .m-form-row-group-item > label Visually hidden labels created for each of the form elements within the molecule if not present

Component releases

  • Added on: v4.15.0 (08/11/19)
  • Updated on: v5.5.0 (23/03/21)

Latest update:

  • updated: Additional aria attributes are now recommended to be applied across all form fields/rows so as to aid screen reader users in completing forms without error and also with understanding and fixing any errors that have occurred.

Full version history

A full history of changes and enhancements detailing all minor and major updates to the component.

View full version history

Want something new in Framework, or to chat about an issue you're having with it?

Contact the team