• Organism
  • CORE COMPONENT
  • Taxonomic name: O-FORM-ASSUMPTIONS
  • Added on: v4.11.0 (19/07/19)
  • Updated on: v5.5.0 (23/03/21)

Form assumptions

The assumptions organism helps to alert customers to the key assumptions used in generating their quote so that they understand what the policy parameters are and have the option to accept or reject these assumptions.


Design and usage

Structure

  • Each assumption should be kept short, clear and concise and provide the right context to what the customer is being quoted for.
  • A few key words in each assumption should be bolded to improve scanning and comprehension.
  • Allow the customer to accept or reject all assumptions at once:

    • Currently unable to accept or reject individual assumptions.
  • Assumptions by default have an orange triangle with an exclamation mark to the left of each assumption:

    • If the customer chooses "False", a notification should appear immediately to provide relevant guidance.
    • If the customer chooses "True", all orange triangles immediately turn into green circles with ticks.
  • A keyline is positioned to the left of the assumptions, from the sub-heading to the bottom of the organism to help frame the assumptions and allows for easier scanning:

    • The keyline colour will always reflect the colour of the icon to the left of each assumption.
  • Contextual help, show/hide or any other organism or module should not be used within the assumptions organism. For any copy that requires further explanation consider placing guidance above or below the organism.

Labels

  • Assumptions will always have true/false radio buttons.
  • The true/false radio buttons will always be preceded by some explanatory text to frame the outcome of their selection.

Notifications and errors

  • A red error state displays above the assumptions organism if the customer submits the form without selecting one of the radio buttons. Customers are unable to progress until they make a selection.

Accessibility and screen readers

  • Assumptions organism should always be used against a light accent background to allow for easy scanning and readability.
  • Body copy should always be #444444 regular:

    • Key word/s to be highlighted in bold.
  • 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.

Non-JS requirements and considerations

  • The left keyline and orange exclamation mark are coloured guide blue #44C0FF and their colour and status do not update upon the customers selection.

Placement

  • The assumptions organism can only be used within a form journey and only once within a group of related form questions, for example questions about "Your home", "Your vehicles", "Your drivers", "Travellers", etc.
  • Multiple instances of an assumption organism can be used on a page.
  • In-line notification placed beneath the true/false radio buttons.

Design anatomy

All break points

  • Vertical keyline and icon colours:

    • Default and false state: #FFA000.
    • True state: #3E812C.
    • Non-JS state: #44C0FF.
  • Vertical keyline:

    • Width = 4px.
    • Height = Height of content + 30px (15px top + 15px Bottom) padding.
  • Typography:

    • H3 sub heading – explanatory text.
    • Body copy regular weight – assumptions description.
    • Body copy bold weight – assumptions key word/s.
    • Body copy – true/false explanatory text.
  • True/false radio buttons follow radio button design rules.

Examples

Interactive example

Code example

<div class="l-max l-max--left [ Modifier ]">
	<fieldset class="m-form-row [ Modifier ] o-form-assumptions" data-module="o-form-assumptions" aria-invalid="..." aria-describedby="...">
		<legend>...</legend>
		<div class="m-heading-group [ Modifier ]">
			<h2 class="m-heading-group__item a-heading a-heading--2">...</h2>
			<h3 class="m-heading-group__item a-heading a-heading--3 a-heading--light">...</h3>
		</div>
		<div class="o-form-assumptions__content">
			<h2 class="a-label a-heading [ Modifier ]">...</h2>
			<ul class="o-form-assumptions-list">
				<li class="o-form-assumptions-list__item">...</li>
				<li class="o-form-assumptions-list__item">...</li>
				...
			</ul>
			<p>...</p>
			<p>If one or more of these is not true, choose 'False'.</p>
			<ul class="m-form-row-group m-form-row-group--option-group">
				<li class="m-form-row-group-item m-form-row-group-item--full-width">
					<label class="a-radio" for="...">
						<input class="a-radio__input o-form-assumptions__input--valid" type="radio" name="..." id="..." value="..." />
						<span class="a-radio__label"><span class="a-radio__label-inner">True</span></span>
						<span class="a-radio__ui"></span>
					</label>
				</li>
				<li class="m-form-row-group-item m-form-row-group-item--full-width">
					<label class="a-radio" for="...">
						<input class="a-radio__input o-form-assumptions__input--warning" type="radio" name="..." id="..." value="..." />
						<span class="a-radio__label"><span class="a-radio__label-inner">False</span></span>
						<span class="a-radio__ui"></span>
					</label>
				</li>
			</ul>
			<div class="m-card m-card-notification m-card-notification--information m-card-notification--background-colour u-hidden u-margin--bottom-none" role="status">
				<div class="m-card-content">
					<div class="m-card-content__inner">
						<p>[Notification message to advise on next steps if assumptions not met]</p>
					</div>
				</div>
			</div>
			<span class="o-form-assumptions__ui"></span>
		</div>
	</fieldset>
</div>

Valid

Errored

Disabled

Development and test

Notes for developers

Radios must be contained within their own fieldset and the legend is the question for the group of radios.

Within a group of radios the name attribute must be common between all the radios, but the id remains unique to the page.

Always have one of the radios within the group set to checked when using switches. If the user has not changed the selected radio option, automatically set the first radio to checked.

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.

If the native form validation needs to be disabled set the novalidate attribute on the form.

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


Notes for testers

  • In this instance the label for the radio option is the wording directly on the right of the radio option. Clicking / pressing the explanitory text for the group of radio options will not transfer focus to any of the radio options like it would for a text input.
  • The label should be displayed to the right of the radio button and should activate the radio button when selected (as should the radio button itself).
  • It should be really clear which label applies to which radio button by using background shading to group the label and the radio button together.

Classes overview

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

Class Outcome Required Applied to Comments
.o-form-assumptions Base style wrapper for form assumptions organism Yes fieldset  
.o-form-assumptions__content Wrapper styling for form assumptions content Yes .o-form-assumptions > div  
.o-form-assumptions-list Styling for form assumptions list Yes .o-form-assumptions__content > ul  
.o-form-assumptions-list__item Styling for form assumptions list items Yes .o-form-assumptions-list > li  
.o-form-assumptions__input--valid Trigger class for javascript Yes .a-radio__input  
.o-form-assumptions__input--warning Trigger class for javascript Yes .a-radio__input  
.o-form-assumptions__ui Styling for vertical keyline Yes .o-form-assumptions__content > span  

Component releases

  • Added on: v4.11.0 (19/07/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