Form layout

What is a form

A form is a structured arrangement of input fields designed to collect data directly from the user. Forms are commonly used for account registration, collecting feedback, simple data entry, and requesting goods or services. The way forms are structured greatly impacts their usability and accessibility, and therefore the overall user experience.

Fields in forms are usually divided into semantic groups of like content via the use of spacing or separate pages to avoid overwhelming the user with too many fields at once. The user is expected to progress through the form linearly, entering minimal amounts of simple and memorable information. This differs from wizards where the user is encouraged to jump around between semantic groupings. Wizards are essentially a series of forms and are better suited for collecting larger amounts of information, or information for which the user must refer to external resources.

Figure 1 shows the use of a form for account registration. The user has requested to register for a Linkedin account and is presented with a form comprised of two simple fields that should be able to be completed without referencing external resources. The form focuses on the essential information required to register for an account, making the task quick and easy. More information such as name, field, and current position could have been collected for future tasks like creating a profile, but doing so may have overwhelmed or deterred the user from creating an account.

Open

Figure 1 - A form prompting a user to register for a Linkedin account.

Structure

The form layout pattern is comprised of several smaller patterns including a heading, input fields and buttons. More information on these patterns can be found below:

Buttons

Labels

Checkbox

When to use this component

• Use forms to collect simple, memorable, and essential data, the user should need little to no external materials to complete

When not to use this component

• Do not use forms to collect large amounts of complex data that the user will need to reference external materials or documentation to provide (use a wizard component instead)

• Do not use forms if the user can’t or may not want to progress through the form linearly

• Do not use forms when users are required to make multiple decisions that impact subsequent fields

Best practices

Do

• Use auto-fill functionality to speed up the process of entering information into the form

• Ensure form fields have visible focus indicators so that users can easily identify which field they are interacting with

• Use visible labels and hint text that are positioned above the associated field

• Clearly indicate mandatory fields using the text ‘Required’ in the field label

• Group similar fields and use cues such as spacing, clear headings, or separating content into multiple pages to break up the form

• Organize fields into a single-column layout. This reduces the chance of a user missing a field and simplifies the reflow of content when the form is viewed in different screen sizes

• Validate content upon submission of the form. Use clear and informative error messages and validation (see Error Summary) to help users understand and resolve their errors

• Upon submission of the form, provide the user with feedback to let them know the form was successfully submitted

Don’t

• Avoid the use of ‘Clear’ or ‘Delete’ buttons that allow the users to clear the content they have entered into the form, unless they are entering sensitive information, such as financial information. These buttons increase the risk of unintended critical errors. If included, they should not be featured prominently on the page

• Avoid using tooltips to provide additional information as they rely on hover interactions which can prove challenging for users of assistive technology or touchscreens. Instead, use hint text if additional information is required to support the user to complete the field

• Don’t disable action buttons due to missing fields or errors, this can lead to frustration if the issue is not immediately obvious. Instead, allow users to submit the form and provide clear error messaging as seen in Error Summary

• Don’t validate fields in real-time as this can be overwhelming to users while they are trying to fill out the form. Instead, validate upon submission

• Don’t rely on visual cues such as color or an asterisk to indicate required fields. Visuals cues may not be conveyed effectively to users of assistive technology and could result in frustration

Tips

• Investigate how similar existing services have organized and grouped their fields to align with user expectations and existing conventions

• Get your users involved in organizing and grouping fields through user research activities such as a card sort

Accessibility 

Designing Accessibility Forms for Everyone

3.3.2: Labels or Instructions 

Providing Descriptive Labels

Technique G131 emphasizes the importance of clear field labels. Each field in a form should have a label that clearly communicates the purpose of the field and what the user is expected to input. Doing so supports all users, especially those of assistive technology, to understand what information is requested.

G131: Providing descriptive labels

Providing expected data format and example

Technique G89 touches on the use of additional instructions to support users in correctly filling out fields. In some situations, such as being asked for a date, the label may not be sufficient because a date could be formatted in many different ways. Using hint text or ARIA attributes can offer additional information to users about the formatting of a field to reduce the chance of entering a value incorrectly.

G89: Providing expected data format and example

2.1.1: Keyboard

WCAG criterion 2.1.1 states that all functionality of web content should be operable through a keyboard. This means that users must be able to interact with and complete a form using the keyboard alone, with no mouse interaction necessary. Users should be able to successfully navigate through the form using the key commands in Figure 3.

G202: Ensuring keyboard control for all functionality

How to keyboard accessibility test a form

4.1.2: Name, role, value

Using ARIA (Accessible Rich Internet Applications) names, roles, and values can help assistive technologies and their users identify UI components and their purpose, making them more understandable and usable. Using ARIA with forms will help convey information about the type of field, its purpose, and its state, making it easier for users of assistive technology to understand and interact with the form.

ARIA Patterns

• Radio Group

• Checkbox

• Combobox

Key component features 

Telerik Blazor Form Component - Overview

Introduction

The introduction to a form can provide users with valuable information about what to expect when filling out the form, such as the estimated time to complete, what kind of information they will be asked to provide, and what supporting documents or resources may be needed. For external-facing forms, a privacy notice statement can be included explaining how the information the user provides will be used and stored. The introduction could be a separate page such as a Service Initiation Page (SIP) or text at the top of the form.

Fields

The fields in a form are made up of labels, the corresponding input, and if necessary, hint text. Common inputs for forms are text fields, radio groups, checkboxes, dropdowns, and comboboxes. Required fields must be marked accordingly so the user is aware of what information must be provided versus what is supplementary. Hint text may also be associated with a field to provide additional guidance or clarification to users to reduce the risk of errors. Form fields should be ordered in a logical order and grouped based on similar content.

Blazor Form Demos - Groups | Telerik UI for Blazor

Blazor ComboBox Demo - Overview

Blazor Checkbox Demo - Overview

Blazor Radio Group - Overview

Blazor Textbox - Overview

Call to Action(s)

There are typically two types of call to action buttons in forms, “Next” or “Submit” buttons and “Clear” buttons. The “Next” or “Submit” buttons are used to indicate the completion of the form to proceed to the next step or submit the form. The text on these buttons should clearly communicate what action the user is about to take and the expected outcome.

When dealing with sensitive information such as financial information, it may be appropriate to include a “Clear” button that allows users to remove any entered data from fields for an increased sense of privacy and protection of data. Use of a “Clear” button should be limited to scenarios such as this as they increase the risk of unintended critical errors and frustrating users. If included, this button should not be featured prominently on the page to minimize the risk of unintentionally selecting it.

See Common UI elements for guidance on English and French button text and Buttons for guidance on button types.

Feedback

Upon submission of a form, it is good practice to provide the user with feedback letting them know if their action was successful and the next steps, if any. This can be displayed as a simple but prominent message on the page indicating the form was submitted and any additional information, such as how long it may take to receive a response or for the service to be completed, and how they can expect to be contacted or receive their product. Any relevant information like a service request number or a contact point to follow up with should be provided as well.

Examples

Open

Figure 4 – Telerik Form component showing a billing address form

Responsive design

In order to be inclusive to all users, we need to consider how our applications behave on smaller viewports. (For more information on viewports, see The viewport is the window to your site – Digital.gov.) While designing and building using responsive design principles will allow you to create an optimized layout for users accessing your application on smaller viewports, this is not the only benefit. This will also ensure you are supporting users with low vision who need to enlarge text by using the browser’s zoom function. 

To help ensure the responsiveness of your application, design forms mobile-first. Organize form fields in a single column, stacking them vertically. This will simplify the reflow of content, avoiding a situation where fields are displayed in an incorrect order. Ensure all fields fit within the boundaries of the smallest viewport. Users should not have to scroll in two directions (horizontally and vertically) to view and interact with content.

Once your design has been implemented, it’s important to test the functionality in various different viewports. Sufficient spacing should be maintained between the fields and labels. All fields and labels should be fully visible, meaning they are not covered or overlapping other content. Figure 5 demonstrates some of the challenges that can arise when forms are not tested in various viewports. Some of the labels and inline error messages overlap making them unreadable, and fields that have been positioned in a horizontal row have shifted due to the labels wrapping.

Resources

Government of Canada resources 

Checkboxes and Radio Buttons

Content Style Guide

External resources 

16 Tips That Will Improve Any Form Design

Website Forms Usability: Top 10 Recommendations

Error Summary - GOV.UK Design System