Overview
Overview
Forms are an essential element within our Design System, serving as vital interactive components to gather user information and facilitate various digital tasks, including user registration, data entry, search queries, and settings configuration.
Key form elements in design systems typically include:
- Text fields: the most common elements, used to gather short, textual user inputs like names or email addresses
- Textarea: a multi-line text field for collecting longer form text input like comments or descriptions
- Radio buttons and Checkboxes: used for selecting one or many options from a list respectively
- Select boxes: useful for presenting multiple options in a constrained space
- Buttons: primarily used to submit the form
- Labels: provide descriptions to the corresponding input fields, enhancing usability and accessibility
- Helper or Hint text: additional descriptive text that guides users in filling out a form
- Validation Messages: provide immediate feedback to users, guiding them to complete the form correctly.
Labels
Labels help users understand what to enter into the field.
Usage guidelines
All text inputs must have labels, and in most cases the label should be visible.
Write labels without a colon at the end. Otherwise, follow the normal rules for using punctuation marks.
Do
- Position labels above the text input they refer to.
- Keep labels short, direct and written in sentence case.
- Best practice suggest labels should be up to 5 words (MOD.UK, n.d).
Don't
- Use colons at the end of labels.
- Use all caps or the form will be harder to scan and read (Babich, 2020).
Hint text
Hint text can be helpful in forms to provide additional information or context to users as they fill out the form.
Help text for entering a tax file number
Tax file numbers are 9 digits
<p>Help text for entering a tax file number</p><br>
<label class="qld__label" for="TFN">What is your tax file number (TFN)?</label>
<span class="qld__hint-text" id="TFN-hint">Tax file numbers are 9 digits</span>
<input type="text" class="qld__field-width--md qld__text-input qld__text-input--block qld__text-input--number" id="TFN" inputmode="numeric" name="Tax file number" aria-describedby="TFN-hint"/>
Hint text
Hint text can be helpful in forms to provide additional information or context to users as they fill out the form.
Usage guidelines
Do
- Use hint text for additional information. Hint text can be used to provide additional information for form fields, such as providing examples of what could be entered in the field.
- Keep hint text short and clear. Hint text should be brief and to the point, so that users can quickly read and understand the information it provides.
- Only use helper text when truly necessary to avoid overloading the user (IMB, n.d).
Don't
- Don't use long paragraphs and lists in hint text. Screen readers read out the entire text when users interact with the form element. This could frustrate users if the text is long (UK.GOV, n.d.).
- Don't include links within hint text. While screen readers will read out the link text when describing the field, they won't tell users that the text is a link (UK.GOV, n.d.).
- Helper text shouldn't run longer than the input area (IMB, n.d).
Required and optional fields
You should indicate to users that a field is mandatory by placing a red asterisk at the beginning of the label.
When designing forms try to only ask for necessary information and where possible avoid optional fields. However, if you can’t avoid optional fields, indicate which fields are options by placing the word 'optional' in brackets after the label.
Required field
Hint text
Optional field
Hint text
<div class="row qld__row-gap-component">
<div class="co-xs-12 col-lg-4">
<p>Required field</p><br>
<!-- Example 1: Required field -->
<label for="required-field-example" class="qld__label">
<!-- Required field indicator using aria-required attribute -->
<abbr title="required">*</abbr>
Text-field label
</label>
<span class="qld__hint-text" id="required-field-example-hint">Hint text</span>
<input type="text" id="required-field-example" class="qld__text-input qld__text-input--block" aria-required="true" aria-describedby="required-field-example-hint">
</div>
<div class="co-xs-12 col-lg-4">
<p>Optional field</p><br>
<!-- Example 2: Optional field -->
<label for="optional-field-example" class="qld__label">
Text-field label
<!-- Optional field indicator using aria-label attribute -->
<span class="qld__label--optional"> (Optional)</span>
</label>
<span class="qld__hint-text" id="optional-field-example-hint">Hint text</span>
<input type="text" id="optional-field-example" class="qld__text-input qld__text-input--block" aria-describedby="optional-field-example-hint">
</div>
</div>
Usage guidelines
Place one of these 2 instructions at the top of your form depending on whether or not you have required or optional fields.
If you have both required and option fields use:
"All fields are required unless marked optional. Required fields are marked with an asterix (*)"
If you only have required fields use:
"All fields are required."
Using the right instruction will make it easier for people to fill in the form and ensure consistency with other forms on the site. Be aware that users often don't read instructions so ensure that you support these instructions by using the appropriate required or optional field indicator.
When to use require fields indicators
Even if most of the fields in your form are required you should still indicate to the user that a field is required. This convention helps users scan forms and increases the chance that your form will get completed correctly the first time (Budiu, 2019).
When to use optional fields indicators
Try to avoid using optional fields in your forms but if you do, always indicate to the user that the field is optional (Babich, 2020).
When not to use optional or required fields indicators
While it's best to incorporate optional and required fields whenever possible there are instances where it may not be necessary. These include forms that are limited to only one field and lLogin forms which are commonly composed of only two fields: the username and the password, both of which are always required (Budiu, 2019).
Validation states and messages
Success
Success messages are used to notify the user when a form field has passed validation. They provide positive reinforcement to the user, indicating that they've correctly filled out the field.
When text input is accepted, a message can display to the inform the user.
Success states are useful in situations like password generation where you can let the user know their password has met syntax requirements, or online tests to let the user know which answers where correct.
<div class="row qld__row-gap-component">
<!-- Example: Success field -->
<div class="co-xs-12 col-lg-4" >
<label for="success-example-1" class="qld__label">Text-field label</label><span class="qld__hint-text" id="success-example-1-hint">Hint text</span>
<span id="example-1-success-message" class="qld__input--success"> <svg class="qld__icon qld__icon--lead qld__icon--sm" role="img" aria-label="Success: ">
<use href="./?a=169317:dist/mysource_files/img/QLD-icons.svg#status-success">
</use>
</svg>
Success message</span>
<input type="text" id="success-example-1" placeholder="placeholder text" class="qld__text-input qld__text-input--block qld__text-input--valid" aria-describedby="success-example-1-hint example-1-success-message">
</div>
<!-- Example: Success field filled style -->
<div class="qld__form-style-filled co-xs-12 col-lg-4">
<label for="success-example-2" class="qld__label">Text-field label</label><span class="qld__hint-text" id="success-example-2-hint">Hint text</span>
<span id="example-2-success-message" class="qld__input--success"> <svg class="qld__icon qld__icon--lead qld__icon--sm" role="img" aria-label="Success: ">
<use href="./?a=169317:dist/mysource_files/img/QLD-icons.svg#status-success">
</use>
</svg>
Success message</span>
<input type="text" id="success-example-2" placeholder="placeholder text" class="qld__text-input qld__text-input--block qld__text-input--valid" aria-describedby="success-example-2-hint example-2-success-message">
</div>
</div>
Errors
Error messages are used to notify the user when a form field hasn't passed validation. Use clear messages to explain what went wrong and how to fix it. For complex forms that have many fields and include hint text, you can choose to further emphasise invalid fields that contain errors by using the emphasised error state that contains a solid red line on the left, this red border visually connects the message and the question it belongs to.
Error field emphasised
<div class="row qld__row-gap-component">
<!-- Example: Error field -->
<div class="co-xs-12 col-lg-4">
<label for="error-field-outlined-example" class="qld__label">Text-field label</label>
<span id="error-field-outlined-example-message" class="qld__input--error"><svg class="qld__icon qld__icon--lead qld__icon--sm" role="img" aria-label="Error: ">
<use href="./?a=169317:dist/mysource_files/img/QLD-icons.svg#status-error">
</use>
</svg>Error message</span>
<input type="text" id="error-field-outlined-example" placeholder="placeholder text" class="qld__text-input qld__text-input--block qld__text-input--error" aria-describedby="error-field-outlined-example-message">
</div>
<!-- Example: Error field filled style -->
<div class="qld__form-style-filled co-xs-12 col-lg-4">
<label for="error-field-filled-example" class="qld__label">Text-field label</label>
<span id="error-field-filled-example-message" class="qld__input--error"><svg class="qld__icon qld__icon--lead qld__icon--sm" role="img" aria-label="Error: ">
<use href="./?a=169317:dist/mysource_files/img/QLD-icons.svg#status-error">
</use>
</svg>Error message</span>
<input type="text" id="error-field-filled-example" placeholder="placeholder text" class="qld__text-input qld__text-input--block qld__text-input--error" aria-describedby="error-field-filled-example-message">
</div>
</div>
<p>Error field emphasised</p>
<!-- Example: Error style emphasis -->
<div class="qld__form-group qld__form-style-filled qld__form-group--invalid co-xs-12 col-lg-4">
<label for="error-field-emphasised-example" class="qld__label">Text-field label</label>
<span class="qld__hint-text" id="error-field-emphasised-example-hint">Hint text</span>
<span id="error-field-emphasised-example-message" class="qld__input--error"> <svg class="qld__icon qld__icon--lead qld__icon--sm" role="img" aria-label="Error: ">
<use href="./?a=169317:dist/mysource_files/img/QLD-icons.svg#status-error">
</use>
</svg>Error message</span>
<input type="text" id="error-field-emphasised-example" placeholder="placeholder text" class="qld__text-input qld__text-input--block qld__text-input--error" aria-describedby="error-field-emphasised-example-hint error-field-emphasised-example-message">
</div>
Usage guidelines
When to use error states and messages
Use error states and messages when users have made an error in their input. This helps to guide them towards the correct input and improves the overall user experience (Nielsen Norman Group, 2020).
When to use success states and messages
Success indicators can be used when users have correctly filled out complex fields. However, these should be used sparingly and only when they provide additional context that helps the user complete the form more accurately or quickly (Nielsen Norman Group, 2021).
When not to use
- Don't use validation messages to communicate issues that aren't related to the user's input. For example, if a user isn't eligible or doesn't have permission to do something, or if there's a lack of capacity or other problem with the service, this shouldn't be communicated through a validation message (GOV.UK, 2023).
- Validation messages shouldn't be used to communicate non-critical information. They should be reserved for important system-status messages that are meant to disrupt the user's workflow and draw attention to an issue that needs to be addressed (Nielsen Norman Group, 2020).
How to use
In order for validation messages to be effective, people need to see them, understand them, and be able to act upon them easily. (Nielsen Norman Group, 2021).
Do
- Display error or validation messages after the error has been made. Wait until a user moves on from a field to display an error message related to an appropriate format (Kaplan, 2022).
- Summarise the errors inside of a Page alert above the form.
- Make error messages easy to notice and understand (Nielsen Norman Group, 2021).
- Make error messages easy to memorise the instructions for fixing the error (Nielsen Norman Group, 2021).
- Be clear and concise: for error messages describe what has happened and tell them how to fix it. The message must be in plain English, use positive language and get to the point (GOV.UK, 2023).
- Use the same message next to the field and in the error summary so they look, sound and mean the same and make sense out of context. This reduces the cognitive effort needed to understand issue has occurred. (GOV.UK, 2023).
- Retain the users input after an unsuccessful form submission.
Don't
- Go overboard with success indicators. Success indicators shouldn’t distract users from filling out forms and should only be used when the additional context helps complete the form faster or more accurately (Nielsen Norman Group, 2021).
- Use technical jargon like ‘form post error’, ‘unspecified error’ and ‘error 0x0000000643’ (GOV.UK, 2023).
- Use words like ‘forbidden’, ‘illegal’, ‘you forgot’ and ‘prohibited’ (GOV.UK, 2023).
- Use ‘please’ because it implies a choice (GOV.UK, 2023).
- Use ‘sorry’ because it doesn't help fix the problem (GOV.UK, 2023).
- Use ‘valid’ and ‘invalid’ because they don't add anything to the message (GOV.UK, 2023).
- Use humorous, informal language like ‘oops’ (GOV.UK, 2023).
- Give an example in the error message if there's an example on the screen such as within the existing hint text (GOV.UK, 2023).
Be conscious if you notice repeated errors (3 or more times) occurring when testing your form, this may indicate a UI issue. Your error messages may not be clear enough, or the design might not meet users' needs. Remember, if users make mistakes, it's likely the design's fault.
Form groups
Used to group form controls and provide structure and consistent spacing within a form. The form group class defines the spacing between form elements. Spacing between from elements is 32px or 2rem.
<!--
The qld__form-group class form group applies spacing between the following two elements
-->
<!-- Example 1: Required field -->
<div class="qld__form-group">
<label for="text-field-spacing-example-1" class="qld__label">
<!-- Required field indicator using aria-required attribute -->
<abbr title="required">*</abbr>
First Name
</label>
<input type="text" id="text-field-spacing-example-1" class="qld__text-input qld__text-input--block qld__field-width--half" aria-required="true">
</div>
<!-- Example 2: Required field -->
<div class="qld__form-group">
<label for="text-field-spacing-example-2" class="qld__label">
<!-- Required field indicator using aria-required attribute -->
<abbr title="required">*</abbr>
Surname
</label>
<input type="text" id="text-field-spacing-example-2" class="qld__text-input qld__text-input--block qld__field-width--half" aria-required="true">
</div>
Fieldset
Fieldset is used to associate a number of related form fields as well as labels within a form. The legend provides an association and caption for the form fields in the fieldset.
For example, you may need to group a set of text inputs into a single fieldset when asking for an address.
<fieldset class="qld__fieldset">
<legend class="qld__fieldset__legend">
<h1 class="qld__display-lg">What is your address?</h1>
</legend>
<!-- Example 1: Required field -->
<div class="qld__form-group">
<label for="address-line1" class="qld__label">
<!-- Required field indicator using aria-required attribute -->
<abbr title="required">*</abbr>
Address line 1
</label>
<input type="text" id="address-line1" name="address-line-1" class="qld__text-input qld__text-input--block qld__field-width--full" autocomplete="address-line1" aria-required="true">
</div>
<!-- Example 2: Optional field -->
<div class="qld__form-group">
<label for="address-line2" class="qld__label">
Address line 2
<!-- Optional field indicator using aria-label attribute -->
<span class="qld__label--optional"> (Optional)</span>
</label>
<input type="text" id="address-line2" name="address-line-2" class="qld__text-input qld__text-input--block qld__field-width--full" autocomplete="address-line2">
</div>
<!-- Example 1: Required field -->
<div class="qld__form-group">
<label for="address-town" class="qld__label">
<!-- Required field indicator using aria-required attribute -->
<abbr title="required">*</abbr>
Town or city
</label>
<input type="text" id="address-town" name="address-town" class="qld__text-input qld__text-input--block qld__field-width--half" aria-required="true">
</div>
<!-- Example 1: Required field -->
<div class="qld__form-group">
<label for="address-postcode" class="qld__label">
<!-- Required field indicator using aria-required attribute -->
<abbr title="required">*</abbr>
Postcode
</label>
<input type="text" id="address-postcode" name="address-postcode" class="qld__text-input qld__text-input--block qld__field-width--1-quarter" autocomplete="postal-code" aria-required="true">
</div>
</fieldset>
Usage guidelines
When to Use
- If your form has multiple related controls, such as a set of radio buttons or checkboxes, you should use
<fieldset>. The<legend>element can then be used to provide a caption or title for the group. - In complex forms with many inputs,
<fieldset>can be used to divide the form into logical sections. This can make the form easier to understand and navigate, particularly for screen reader users.
When not to use
- If your form only contains a single control (like a search box), there's no need to use
<fieldset>. A simple<label>and<input>would suffice. - If your form contains unrelated controls, it's not appropriate to group them together with
<fieldset>.
Form example
The HTML <form> element is used to create a HTML form for user input. The <form> element is a container for different types of input elements, such as text fields, checkboxes, radio buttons, submit buttons, etc. Below is a simple example of how you can structure a form using some of the form components above.
Simple form
Introductory paragraph providing context for this form.
<h2>Simple form</h2>
<p>Introductory paragraph providing context for this form.</p>
<hr class="qld__horizontal-rule--lg">
<form>
<fieldset class="qld__fieldset">
<legend class="qld__fieldset__legend">
<h3 class="qld__display-md">Section heading</h3>
</legend>
<!-- Example 1: Related Required field -->
<div class="qld__form-group">
<label for="related-text-field-example-1" class="qld__label">
<abbr title="required">*</abbr>
Related text field heading
</label>
<span class="qld__hint-text" id="related-text-field-example-1-hint">Hint text</span>
<input type="text" id="related-text-field-example-1" class="qld__text-input qld__text-input--block qld__field-width--half" aria-required="true" aria-describedby="related-text-field-example-1-hint">
</div>
<!-- Example 2: Related Required field -->
<div class="qld__form-group">
<label for="related-text-field-example-2" class="qld__label">
<abbr title="required">*</abbr>
Related text field heading
</label>
<span class="qld__hint-text" id="related-text-field-example-2-hint">Hint text</span>
<input type="text" id="related-text-field-example-2" class="qld__text-input qld__text-input--block qld__field-width--half" aria-required="true" aria-describedby="related-text-field-example-2-hint">
</div>
</fieldset>
<hr class="qld__horizontal-rule--lg">
<!-- Example 3: Isolated Optional field -->
<div class="qld__form-group">
<label for="isolated-text-field-example" class="qld__label">
Stand alone field
<!-- Optional field indicator using aria-label attribute -->
<span class="qld__label--optional"> (Optional)</span>
</label>
<span class="qld__hint-text" id="isolated-text-field-example-hint">Hint text</span>
<input type="text" id="isolated-text-field-example" class="qld__text-input qld__text-input--block qld__field-width--half" aria-describedby="isolated-text-field-example-hint">
</div>
<hr class="qld__horizontal-rule--lg">
<!-- Submit button -->
<div>
<input type="submit" class="qld__btn" name="submit" value="submit">
</div>
</form>
General usage guidelines
Below are general guidelines for forms. It's also recommended that you review the Australian Government Style Manual for more detailed advice on form content.
When to use forms
Forms are used to capture data from users.
You might design a form for a user to:
- create and account or login
- register for a service
- configure settings
- fill in a survey and provide feedback
- purchase a product
- search for something.
When not to use forms:
Don't use forms if the user is performing a simple action that doesn't require additional information, such as liking a post or downloading a file. A simple button or link will work better in these instances.
Don't use forms to display information. Forms are for collecting input, not displaying output. If you're simply displaying information to the user, use other UI elements like text, images, tables, or lists.
How to use forms
Do
- Try to keep forms to one column, multiple columns easily disrupt a user’s vertical momentum (Digital NSW, 2022).
- Use the right sized text inputs. Make sure the text boxes match the expected content size for what they need to write. This will help convey to them that what they're inputting is correct (UK.GOV n.d.)
- Group Related Fields. If your form has many fields, group related fields together using subheadings or fieldset elements to make the form easier to navigate and understand.
Don't
- Mix the outlined style and filled style of a text field in the same form.
- Use all caps for labels, validation messages or hint text.
- Disable copy and paste. Users often need to copy and paste information into a text input, so don't stop them from doing this (UK.GOV n.d).
- Ask for Unnecessary Information. Only include fields that are absolutely necessary. Each additional field increases the effort required to fill out the form and can deter users.
Other best practice
Number of text fields per page
When it comes to designing forms, and using text input components a good rule of thumb is that shorter is better, less effort on the part of the user will lead to higher completion rates.
Try to always limit the number of text fields as much as possible. Overall this will make your forms feel less bloated, especially when you’re requesting a lot of information. Displaying only 5 to 7 input fields at a given time is a common practice (Babich, 2020).
Background colours
It's recommended where possible to use white backgrounds for long forms. White backgrounds provide a clean, uncluttered canvas for forms, making them easier to read and fill out. This can help reduce user frustration and increase completion rates.
Avoid placeholder text
Research completed by GOV.UK (n.d.) and research from Nielsen and Norman group (2018) suggests that you shouldn't use placeholder text in place of a label, or for hints or examples, as:
- it vanishes when the user starts typing, which can cause problems for users with memory conditions or when reviewing answers
- not all screen readers read it out
- its browser default styles often don't meet minimum contrast requirements.
The only time that you may need placeholder text is to indicate unconventional formatting that a user may be unfamiliar with. Placeholder text provides hints or examples of what to enter (e.g. YYYY-MM-DD). However, since placeholder text disappears once the user begins to input data, it should never contain crucial information.
Multiple Design Systems in our comparative analysis recommend that alternatives such as tool tips be used to convey this information.
Numbers
If you’re asking the user to enter a whole number, set the inputmode attribute to numeric to use the numeric keypad on devices with on-screen keyboards (UK.GOV, n.d).
Don't use <input type="number"> unless your user research shows that there’s a need for it. With <input type="number"> there’s a risk of users accidentally incrementing a number when they’re trying to do something else - for example, scroll up or down the page (UK.GOV, n.d).