By default, and unless instructed otherwise in these or other applicable guidelines, text should be:
black or very dark grey (for example #000000 or #0C0C0C)
a non-Roman ('sans-serif', that is, without the small lines at the end of the character), typeface is highly readable on screen, especially at small sizes (for example Arial, Helvetica, Optima, Verdana, Tahoma, Open Sans). For more information, visit .
set flush left
actual text, not an image of text. If text must be provided via an image, ensure appropriate ALT text is provided.
set relatively (that is, in ems or percentages, not pixels)
The size of text used for answers should be the same as for questions (including labels on radio buttons and check boxes). The background colour of a form should be white (that is, #FFFFFF), unless a different colour is needed to improve usability. If the background has a colour, it should be a tint of no more than 10%.
Slot gameBecause not all form-fillers can perceive it, colour should never be used as the sole method of conveying information. Except for very large text and help text, the contrast between text and background colours (for example on buttons) should be at least 8:1, as recommended by the W3C. Large text should have a contrast of 3:1. Help text should have a contrast ratio of 4.5:1.
Link text should be underlined, and in a different colour from the surrounding text. If link text isn't underlined, the contrast ratio for the link text colour versus the surrounding text colour should be at least 3:1. There are several free tools available for checking colour contrast, including:
Slot gameFor more information on colour contrast, visit the .
Form title
Slot gameEvery form must have a unique, descriptive title. Avoid using redundant terms like 'form', 'online' or the name of the business unit (the header says this). Set the title in the largest font used anywhere in the form, and position it flush left. Programmatically, use the h1 element to mark up the form title.
When choosing a title, put the subject before the verb. This makes it easier to find the right form, as when searching, form-fillers are focused on the subject matter more than the related action.
The exception to this rule is forms within a user portal, such as the forms inside the Working With Children Check Unit’s MyCheck. In-portal forms are usually for performing actions on the user’s account, so are more appropriately named with verb before the subject.
When referring to a form in the text of a website, use the exact form title.
Good title
Poor title
Example of reference in text
Birth registration
Register a birth
'...complete a Birth registration...'
General complaint
General complaint - Consumer Affairs Victoria
'...make a General complaint...'
(In a portal) Change your details
(In a portal) Details change
'...change your details within 21 days...'
Contact information
Form-fillers should have access to telephone support during appropriate hours. Telephone support enables form-fillers to move past blocks — such as being unsure how to answer a question — in the most frictionless way (that is, while still on the relevant screen of the form).
In turn, for the business unit, this improves data quality and reduces costs. Data quality is improved because on required questions, form-fillers can give accurate answers (rather than guessing or providing nonsense answers, just to get past validation).
The Working With Children Check Unit experienced inserting of nonsense answers first hand. When a field was required but some form-fillers legitimately didn't have any answer for it, the Unit started receiving submissions with spaces, dashes, full stops or other single characters entered.
Costs are reduced because:
it's easier and more efficient to help a form-filler at the point where they incur the issue, rather than later
improved data quality means less staff time spent addressing data issues after submission
always-visible contact information provides psychological reassurance to form-fillers, and helps build trust. It says: 'if you need help you'll be able to get it easily'. This makes form-fillers more willing to try completing the form online, and increases adoption of this more cost-effective channel
Making it easy to contact the owning organisation is one of Stanford University’s 10 guidelines for building site credibility. These guidelines are based on the considerable research done by the Stanford Persuasive Technology Lab — three years and 4,500 people — as listed on their website
Slot gameMoreover, if they need it, form-fillers will find contact information one way or another. Thus, displaying the details on the form will not significantly increase call volumes, yet it will improve form-filler satisfaction.
How to provide contact information
Slot gameProvide a brief description of the support and its availability (days, hours and time zone), for example:
Make this information always visible no matter what step of the form the form-filler is on. Contact information can be set flush right.
Form headings
Form title
As mentioned earlier, every form has at least one heading: the form title. The form title is the largest font in the form.
Step headings
Single-step forms don't need a step heading; the form title suffices. Multi-step forms should have a heading for each step. This heading should be set flush left, in a font that is smaller than the form title but larger than message headings. Programmatically, use the h2 element for step headings.
Slot gameStep headings should be brief (that is, 1–5 words). Avoid the use of redundant terms like 'details' and 'information'.
Summary message headings
Slot gameBoxes showing summaries of errors, warnings or feedback should include a heading, as follows:
Message type
Heading
Errors
To continue, please...
Warnings
Note
Reinforcement
Success (or equivalent)
Information
Important
The font for message headings should be smaller than step headings but larger than section headings.
Section headings
Avoid section headings (but not necessarily sections themselves). Research shows form-fillers often use section headings to decide whether they need to complete the section, so section headings increase the chance of errors.
Where used, section headings should describe what the section is about. Never use a section heading to ask a question.
The font for section headings should be smaller than message headings but larger than that used for field labels and question-level help. Like field labels, section headings should be set flush left:
Slot gameIf a form screen is broken into sections, programmatically the fieldset element and legend tag should be used to create and caption the sections for screen readers. To mark up section headings, use the h2 (if the form is single-step) or h3 (if the form is multi-step) element.
Page title
Slot gameEvery screen of the form should have a unique and meaningful page title (that is, the browser tab or window label), marked up using the title element. By default, the page title should be 'Step heading – Form title'. The business unit name can be appended to the page title.
Progress indicator
Display a progress indicator when a form has more than one data-entry step, not counting Eligibility or Review (refer to Layout of forms - key screens). The exception is when the form is being viewed on a mobile/small screen. In this case, the progress indicator should be a simple label indicating which step the user is on, and the total number of steps contained within the form for example 'Step 1 of 5', 'Step 2 of 5', etc.
Because the steps in the form must be completed in a specific, linear sequence, sometimes with dependencies between steps, no parts of the progress indicator should be clickable. If a multi-step form has no dependencies between steps, and steps can be completed in any order, a tabbed form design should be used rather than a progress indicator.
Slot gameA standard for the design of a tabbed form isn't provided here because at the time of writing, there were no prototypical forms of this type. Moreover, the tabbed form is relatively uncommon on the web, and so international best practices aren't yet established. If you use a tabbed web form in the future, test the design thoroughly with users before going live.
The progress indicator should have one 'node' for each step in the form, including Review but excluding Eligibility (page 101) and Completion (page 106). The label for each node should be exactly the same as its corresponding step heading. don't number steps or use redundant terms like 'step' or 'page'.
Slot gameEach node can have one of three states:
current step
step yet to be started
completed step
Each state should have a different background colour, with the current step being the most visually prominent. Default colours should be:
Node state
Background colour
Current step
Brand colour, ideally primary (provided sufficiently different from grey or green)
Step yet to be started
Grey (for example #BFBFBF)
Completed step
Green (for example #D2FABE)
Slot gameCompleted steps should also have a tick icon (for example in colour #327828). Reinforce the sequential nature of the form by linking nodes with a directional arrow. Make sure there's enough space between nodes so that their labels don't come to close to each other. If necessary, wrap labels, but ideally not over more than two lines. Node labels should be set centred, vertically aligned with the middle of the node.
An example of a progress indicator that meets these requirements is shown below. 'Mother' is the current step:
In the progress indicator, don't include Introduction, Eligibility or Completion. (Refer to Layout of forms - key screens.)
The content of the progress indicator should be conveyed to screen reader users (for example use ALT text for nodes — if nodes programmed using HTML images — or hidden CSS — if nodes are CSS background images).
Numbering
Sub-questions
Don't number sub-questions.
Questions
Slot gameBy default, questions should not be numbered. Number questions if you need to refer to them.
Question numbering should be in numerals (that is, '1, 2, 3…'). If you are numbering questions, your questions will usually be long and thus flush left. In such cases, there should be a hanging indent so the question number stands out from the text. The numbers can be written either with a prefix of 'Q' and without a full stop, or without the 'Q' and with a full stop:
.
Use this principle throughout the form, including communicating:
which labels go with which fields
which tips go with which labels
which radio buttons or check boxes form a set of response options
which sub-questions make up a question
Zebra striping
When additional separation is needed, zebra striping works well. Zebra striping is the alternate application of a very light grey tint (for example #E6E6E6):
Case
All text should be in sentence case. This means capitalising the first letter of the first word (of the title, label, tip etc) but not capitalising any other letters:
.
Fields - overview
Slot gameThe overall structure of the form body should be as follows:
Slot gameThe 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.
Slot gameDon'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:
Slot gameText 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 formsSlot game, 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:
Slot gameRemember 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.
Slot gameOn 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:
Width
Suits
Smallest
Small numbers (for example 1 or 2 digits)
Small
Postcode, abbreviated Australian states
Large
Suburb or town, phone number, country, sex, occupation, ABN
Largest
Street, name, email address, relationship status, indigenous status
Slot gameBy 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).
Slot gameWhen 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.
Slot gameIf the form-filler can choose only 1 option, use radio buttons, else use check boxes.
Slot gameRadio 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:
Slot game Never horizontally:
The one exception is the ease of use rating question asked after the form has been submitted. For more information, see Form feedbackSlot game. 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.
Slot gameDrop 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.
Slot gameIf 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.
Text fields
Except for dates, there should only ever be one text field per label. This means numbers like ABN or credit card are to be collected via a single text field, rather than multiple text fields (one for each 'chunk').
Do this:
.
Dates are an exception because they are actually three fields combined into one: day, month and year:
. The table below shows the action that should occur when each of the navigation elements is used:
Element
Action
'Next' button
Load the next step in the process, anchored at the top of the screen.
'Back' button (Ideally, the browser’s back button should trigger the same action as the form’s back button)
Load the previous step in the process, anchored at the top of the screen.
'Cancel' link
Slot gameTrigger a modal dialog with two buttons: one button returns the form-filler, at the same scroll position as when 'Cancel' link was used; one button closes the window the form is in and discards the session from the server.
An example of a cancel dialog:
Slot gameAfter 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.
Slot gameLabel in upper case:
Slot gameButton 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:
Slot gameDon’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).
Slot gameAs 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.
Slot gameOn 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.
Slot gameConversely, 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.
Attachments
Where attachments can or must be uploaded with the form, follow this structure:
'Attachments' heading
clear description of what should or must be attached
bullet points on acceptable file types and sizes
files (as they are attached)
button to select file.
Slot gameFor example:
Slot gameThe button to select a file should bring up the operating system’s file explorer tool. The screen should stay anchored to the Attachments section throughout the attachment process.
Messages in forms
At a form- or step-level, 'messages' includes:
text about required fields, that is, 'All questions must be answered unless marked '(Optional)'.
step-level help
general information
summaries of
validation failures (that is, errors)
warnings
positive feedback (that is, reinforcements).
At a question-level, 'messages' refers to individual errors, warnings and reinforcements.
By default, and aside from any headings, all messages should be presented in the same font size, weight and colour as questions.
Slot gameAll messages should be written in plain English, with a polite, non-accusatory, tone. For errors, the focus should be on what must be done in order to progress, not what was done 'wrong'.
Slot gameExcept for warning messages about cancelling or timing out of a form, all messages should be within the form screen, not in a modal window.
Errors, warnings, information, and reinforcements should be colour-coded and marked with an icon:
Message type
Icon description
Icon example
Slot gameHeading 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
Slot gameThe 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.
Slot gameUse 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.
Slot gameExample of an error message summary:
Slot gameExample 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.
Slot gameInline 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.
Slot gameUnless 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)
Slot gameIf 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).
Slot gameBy 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.
Slot gameIf 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.
Get advice and share your insights about this topic with other digital practitioners on the (VPS access only).
Can’t access Yammer? Contact us by email: digital@dpc.vic.gov.au (We may post your comment on Yammer for general discussion. Please tell us if that’s not OK.)
