Layout of forms, key components - digital guide

The overall structure of the form body should be as follows:

The column for section headings (dark grey) field labels (green) should be anchored to the left edge of the form body and run across to the form spine. The column for the fields (purple) and navigation (blue) runs from the form spine to the right edge of the form body.

Don't centre the spine in the form body. Instead, locate the spine to the left to suit the length of the majority of questions — so the labels and fields aren’t left floating in a sea of white space — while also ensuring there isn’t too much text wrapping.

Do this:

Don’t do this (spine too far to the right):

While the field labels are aligned in a column, with the fields themselves aligned in another column, the tab order should be set for logical form-filling flow:

Within the left-hand column for field labels and question-level help (the green box in overall structure above), text should be set flush left:

On a mobile/small screen:

Text that is set flush left is the easiest to read, while zebra striping helps guide the eye to the field, when the label is to the left of, rather than above, the field. Zebra striping may also help associate visually the label and help text with the field on mobile/small screens.

If more than 75% of the form’s fields have labels that are brief stubs (see Q&A in forms, and the section on full sentence question vs. brief stubs), and move the form spine further to the left and reduce the width of the field label column. This is illustrated by this example.

Do this:

Don’t do this:

Within the right-hand column for fields (the purple box in the illustration of overall structure), this is how radio buttons and check boxes should be laid out:

This approach follows the established convention for the web, and allows all radio buttons and check boxes to be vertically aligned, for fast completion.

Any zebra striping should go to the edge of the form body (the grey box in the illustration of overall structure). In other words, zebra striping extends beyond the edge of field labels and fields:

Remember that when labels are to the left of fields, zebra striping must be used. Zebra striping is optional in all other cases. The one exception is a log in form, where the username and password need to be visually grouped, so no zebra striping should be applied.

On mobile/small screens, the same structure applies, except field labels and question-level help should be positioned above fields, rather than to their left.

Don't make all text and drop down fields the same width. The width of the field is a visual cue to the form-filler, helping them know what kind of information is needed.

However, to maximise aesthetics and simplicity, variety in field widths should be kept to a minimum. Aim for no more than four different widths within one form, for example:

By default, drop down fields should be formatted to one of these widths, rather than having the width of the largest entry.

Programmatically, every field must have a label and the field and label must be associated using the for attribute. Don’t visually hide labels unless the surrounding context makes them unnecessary.

Labels must be in close proximity — vertically or horizontally — to their associated fields.

When focus is on a form field, of any type, all keystrokes should act on that field. In particular, backspace and enter should act on the field only (if at all) rather than triggering the 'back' function in the browser or submitting the form.

If you want to provide the form-filler with a set of options to choose from, this is a 'closed' question. Closed question response options can be presented in a number of ways, but the most common are:

• radio buttons
• check boxes (also known as tick boxes)
• drop downs (also known as selects)

The alternative to a closed question is an 'open' question, where the user can provide any answer they like, into a text field (also known as an input field).

When there are 3 or fewer options, use radio buttons or check boxes. This saves the form-filler a click (to go into the drop down), and allows them to see all the options that are available, at a glance.

If the form-filler can choose only 1 option, use radio buttons, else use check boxes.

Radio buttons and check boxes should be implemented such that the label for each option can be used to make a selection, not just the circle or square that is the actual radio button or check box.

Radio buttons and check boxes should always be positioned vertically:

Never horizontally:

The one exception is the ease of use rating question asked after the form has been submitted. For more information, see Form feedback. Programmatically, each set of radio buttons or check boxes should be grouped within a fieldset. The fieldset should be titled using the legend tag.

For 4 or more options where the form-filler can choose only one option, use a drop down, else use checkboxes.

Drop downs should be implemented so that the keyboard can be used to jump to the first matching option, where one or more characters — anywhere in the option — are being matched.

If the form-filler has to choose between a large number of options — for example 20 or more — look to see if the question can be broken up or changed in some way.

Research shows that form-fillers take the size of a text box as an indication of how much information is expected. As such, if an answer of more than one line is typical and allowed, the text field should be multiple lines high:

Prefixes and suffixes can be used to minimise data entry and cue of the kind of information that is needed:

The prefix or suffix can appear outside or inside the text field, but should not be editable:

Note that for the purposes of vertical alignment, a prefix should be considered the start of the field.

Don't use placeholder text inside fields (text or drop downs).

Across all online forms, the majority of questions should be mandatory (or 'required'). This will often be the case at a form level too. If, at a form level, the majority of questions are optional, it may mean you are collecting too much unnecessary information. Look at whether questions can be cut from the form.

As the majority of questions are mandatory, the screen will be kept free of clutter — while still providing a highly usable and accessible experience — if you mark just those questions that are optional.

Indicate optional questions by adding the grey text '(optional)' to the end of the field label:

The grey used for the '(optional)' text should be the same as the grey used for question-level help.

On every form screen, underneath the form title — or step heading, for multi-step forms — there should be an explanation of this approach:

This explanation should also be included in the introduction for the form.

If completion rates for an optional field are too low, consider explaining to the form-filler how providing the information will help:

Note that a question is only required if it must be answered by all form-fillers, in all cases. For example, for WWCCU forms, if a person has only one name, it goes in the family name field. Thus, given name is not a required field for all form-fillers, in all cases, and should not be marked as required.

All required questions should be indicated as such programmatically.

Finally, if a question has multiple sub-questions, and the requirement is that at least one sub-question is answered, then do this:

In this approach:

• the help text 'At least one must be provided' is added immediately after the field label
• visually, sub-questions are not marked as '(optional)'

Fields that are related to each other – such as the parts of an address – should be in close vertical proximity:

A 'conditional field' is one that is applicable in only a subset of cases. An example is postal address, which only needs to be collected if it's different from the already-collected residential address. The term 'conditional' refers to the fact that the need to ask the question is conditional upon the answer(s) to earlier questions.

Conditional fields should be hidden (both visually and programmatically, using the aria-hidden attribute) until they are confirmed as applicable, as illustrated in the following sequence.

Screen upon loading:

Screen after address has been entered by form-filler:

Screen after form-filler answers 'No' to postal address question:

The showing of conditional fields can be triggered by an on-input event handler, but never by on-focus.

there's no need to provide a non-JavaScript version of the form to account for conditional fields, sometimes referred to as 'graceful degradation' — provided the:

• conditional fields always appear below the triggering field
• screen does not reload to show the conditional fields
• screen remains anchored on either the triggering field or the first conditional component shown
• JavaScript follows specification

The trigger question is the field that determines whether or not a conditional field is shown. In the example above the trigger question is 'Is your postal address the same as your residential address?'

If a form-filler goes back and changes their answer to a trigger question so that the conditional field(s) are no longer shown, then any data that had been entered into those conditional fields should be deleted.

Forms will sometimes have sets of fields that can be repeated one or more times (up to some very high limit). For example:

• someone who works with children may do so at one or multiple organisations
• a mother can have any number of previous children
• there may be multiple related parties to a complaint

It makes sense — for form-fillers and government — to use the same set of fields for each instance. However, it can be tricky to do this in a usable way, so carefully follow this procedure when setting out the interface:

Note:

• there's only ever one 'add another' button, and this button always appears underneath the last set of repeated fields
• whenever there's only one instance of a repeated fields set, there should be no 'remove' button against the heading for that set (so that only the radio buttons control whether this instance is shown)
• for repeated fields, zebra striping should be applied at a set- rather than question-level

To illustrate, here is how the screen will look when the form-filler has entered the details of one organisation and just used the 'Add another organisation' button, intending to enter the details of a second organisation.

First principles of interaction design underpin this design. Moreover, the approach has been used successfully in two complex web form designs for Coles, and successfully tested with a total of 29 research participants from a cross-section of the general public.

This procedure has been recommended because:

• it's consistent with the presentation and behaviour of other fields in the form
• it allows the user to add and remove sets of repeated fields in any order
• it's highly scalable, to any number of repeated field sets

When there must be at least one instance

The above procedure is for cases where it's okay to have no instances of the repeated field(s).

If there must be at least one instance of the set of repeated fields, the procedure is the same, except:

• the 'ask if any' question is not shown
• the button to removed the first instance is not provided
• the second to nth instances are labelled 'other' for example 'Second other organisation'

This adjusted procedure is illustrated by the next diagram.

Display notes for repeated fields

Regardless of whether or not there must be one instance of the repeating field:

• the repeating instances of the field(s) are conditional fields, and so should be hidden by default
• the 'add another' button is spaced vertically away from the repeating set of fields, to convey its relationship to the form as a whole, rather than the set

Procedure for when there must be at least one instance:

Limit on the number of sets

If there must be a limit on the number of sets, make sure this limit is high enough so that the vast majority of form-fillers (for example 95%) won’t ever reach the limit.

When the form-filler has added the maximum number of sets, replace the 'add another' button with a message indicating this limit and what to do if there's a genuine need for more sets than allowed:

'Navigation' refers to the way form-fillers move between steps or screens. The recommended approach is, in this order:

• a 'primary' navigation button, for moving forward
• a 'secondary' navigation button, for moving backward
• a link, for cancelling out of the form

As shown in structure of the screen, these navigation elements should appear underneath the form body. Have the left edge of the primary button in vertical alignment with the left edge of fields:

These three components should be:

spaced evenly (that is, same space between 'Next' and 'Back' as between 'Back' and 'Cancel')

far enough apart so that they are clearly three separate elements

close enough together to form a 'set' of functions

The primary navigation button should have:

• a label of 'Next', in bold
• a colour that is highly prominent and ideally the primary brand colour (unless that colour is a red)

The secondary navigation button should have:

• a label of 'Back', not in bold
• grey colour

The 'Cancel' link be:

• labelled 'Cancel'
• blue-coloured, underlined text, with no background colour, by default
• styled consistently with other links in the form and on the site

All of the above recommendations about navigation buttons and links draw on research findings about the most effective order, styling and presentation for such form components. For more information, visit Buttons on forms and surveys: a look at some research 2012 - Slideshare website. The table below shows the action that should occur when each of the navigation elements is used:

An example of a cancel dialog:

After the last field on the form, the tab order should be:

• primary navigation button
• secondary navigation button
• cancel link

The last button on the form — the one to 'submit' the form for processing — should, at a minimum, have the styling of the primary navigation button. The same applies to the button that triggers the first screen of data entry: the 'start' button. Ideally, though, the start and submit buttons will be made even more prominent than any other button in the form, by doing one or more of the follow.

Label in upper case:

Button size increased:

Button styling more prominent:

Combination of upper case, larger button size and more prominent button styling:

Avoid 'submit' as the label for the submit button. Instead, the label should describe whatever action the form-filler will be taking when the button is used. This will usually be the same as or similar to the form title.

The start button should be labelled 'Start now'.

Buttons can be styled to match the style of the corresponding website provided the aforementioned criteria are met and buttons look clickable. Ways to achieve this include having a drop shadow, rounded corners, gradient or border, no matter how slight or subtle.

Button labels should be set centred on the button. When the label is especially short, make the button larger than the label, to provide sufficient target area.

Do this:

Don’t do this:

When the mouse cursor or keyboard focus is on a button, the pointer should change to a hand and the colour of the button should change colour (for example to a lighter or darker tint).

As shown in all the above illustrations, navigation buttons should have a tip underneath them, styled as per question-level help except that the text is centred. On all but the start and submit buttons, this tip should say 'To: step heading'.

On the start button, the tip should say: 'Using our secure service', to reassure form-fillers that it's safe to enter personal data. This assumes that all forms use https for an encrypted transmission of data.

On the submit button, the tip should either:

• say 'To: Confirmation' or
• give an indication of what will happen after the form is submitted (if submission is not the end of the process).

All button tips can wrap to accommodate longer labels, but over no more than three lines. Tertiary buttons don't need button tips, nor do 'Edit' buttons at Review (both have very descriptive labels).

By default, buttons should never be disabled or hidden. A disabled button tells the form-filler the button can’t be used, but it doesn’t tell them why it can’t be used. This potentially leaves the form-filler stuck and unable to continue. A form-filler has no way of knowing that a hidden button will appear, potentially leading to significant confusion.

Conversely, if all buttons are enabled at all times, and a button is used before prerequisite actions have been done, this can be explained via Messages.

Errors, warnings, information, and reinforcements should be colour-coded and marked with an icon:

Message type	Icon description	Icon example	Heading text colour	Background colour
Errors	Exclamation mark on a circle or octagon		Red (for example #D302020)	Pink (for example #FFE6E6)
Warnings	Exclamation mark on a pyramid		Dark orange/mid brown (for example #AA551E)	Light yellow/Light orange (for example #FAF0D7)
Information	Letter 'i' on a circle or octagon		Dark blue Background: #d2dce6 Heading text and info icon: #0F3769 Body text: #000000	Light blue (for example #D2DCE6)
Reinforcements	Tick on a circle or octagon		Green (for example #327828)	Light green (for example #D2FABE)

The use of an icon is important for accessibility (for example so information isn’t being communicated only through colour) and cognition.

So that they can be clearly associated with their meaning, the above colours should be relatively unique, that is, not the same as key branding colours. The colours should also not be used elsewhere in the form for any purpose other than indicating errors, warnings or reinforcements.

Summaries of errors, warnings and reinforcements should comprise:

• icon (hanging out the left hand side, to catch the eye)
• heading (see Headings for text to be used in message headings)
• content of message

All server-based errors, warnings and reinforcements should be presented at once, rather than sequentially. For errors, the content of the message should be split into two sections:

• 'Answer these questions': Required question or sub-question that was not answered
• 'Provide a valid answer to these questions': Required question where the answer is not in the right format

The bullet point for each part uses the exact field label and is an anchor link to that question in the form. When the error field is a sub-question, present the question and the sub-question as the anchor link.

Use bullets and the wording above even if there's only one bullet point for a given part. don't show parts that have no bullet points.

Example of an error message summary:

Example of a warning message summary:

Example of a reinforcement message summary:

If the page has to reload to show a message summary, add 'Error(s) in form –', 'Warning –' or 'Success –' to the start of the Page title. Otherwise, move focus to the icon in the summary message.

The icon, background shading and text colour (used here for the error messages) should be repeated at the question-level, as per the following example:

Note how:

• the icon is again hanging out to the left hand side, to facilitate scanning
• background shading overrides any zebra striping
• the wording of the text for the question-level error message (for example, 'Please answer this question') matches the text in the summary (for example, 'Answer these questions:')
• the question-level error message is located before, but in close vertical proximity to, the field label
• the message for formatting errors doesn't specify the invalid character. This is because on fields where the acceptable character set does not meet form-filler expectations — for example, apostrophes not being allowed in text fields — the field will have always-visible help text advising which characters cannot be used

For accessibility, the question-level error message should be part of the label element for the question itself.

Inline validation is where the validity of the field is checked — and errors reported on — as soon as the form-filler moves to the next field.

Unless the entire form can be validated inline — that is, the form is very brief and simple — this technique shouldn't be used. This is because on complex forms:

• significant server-side validation will be needed in addition to inline validation, creating inconsistency and user confusion (a field that doesn’t trigger an inline validation message is not necessarily correct)
• research shows form-fillers don’t correct errors as well if inline validation is used
• research also shows form-fillers find inline validation makes for a subjectively worse user experience (presumably because it interrupts flow)

If the form is very brief and simple, and inline validation can be used on the entire form, inline validation messages should use the same wording, colouring and iconography as server-side messages (see above).

By default, general information will be presented as normal text. However, if it's important to call out a piece of general information, you can use an approach equivalent to that for errors, warnings and reinforcements, with an 'i' icon and blue as the base colour (for example #0F3769 for heading text and #D2DCE6 for background):

When the system is processing a form-filler’s request — for example, loading the next step of the form — a processing animation and text should play over the relevant form component:

It’s important to include the text 'Loading…' as not all users will understand what the animation means. The movement in the animation, reassures the request was received and is being processed.

If the system is loading the next step or screen of the form, the whole screen should have a grey overlay, to convey the current step or screen should not be used. The loading animation should be presented on top of this overlay. All buttons on the screen should also be disabled.