Overview
The form component is intentionally minimal by default, allowing it to adapt to a wide range of use cases and layouts. It’s designed to be flexible, with responsibility placed on the user to configure and extend it as needed. For detailed design guidance, refer to the form pattern.
Text block (optional)
An optional section at the top of the form that includes a heading and description. Use text block to provide context or instructions to help users understand the purpose of the form.
Form body
The main content area where users enter information. It can include a variety of input components such as text fields, checkboxes, radio buttons, and more. Each input should include a label and may include helper or assistive text to guide the user in entering valid data.
Form actions
Located at the bottom of the form, this contains form actions such as “Submit” or “Cancel”. These actions allow the user to complete or exit the form process.
Vertical spacing
A vertical spacing of 32px / 2rem between components is typically recommended. For full spacing guidance and best practices specific to forms, refer to the form pattern.
Input labels
Clear labels help users understand what information to enter in a text input. Every text field should have a label. In rare cases where the input’s context is unmistakable, a visible label may be omitted—but consult an accessibility specialist before doing so.
- Label best practices
- Use sentence case, except for product names and proper nouns
- Keep labels short and clear
- Do not include colons after label text
Default values
Where appropriate, provide programmatic assistance by detecting and pre-filling input values to minimise user effort and reduce the risk of errors. When values can’t be determined automatically, offer type-ahead suggestions. Use sentence case for all default, detected, and auto-complete text.
Assistive / Helper text
Optional assistive and helper text provides users with relevant information to support accurate field completion. These supporting texts help clarify data entry requirements and improve usability, particularly for more complex inputs.
Assistive text sits directly below the input label and provides brief, contextual support that complements the label, such as offering a short explanation of what’s being asked. It helps set expectations before the user interacts with the input.
Helper text appears persistently beneath the input field and offers additional guidance, such as formatting instructions, example values, or further explanation. It is the preferred method for assisting users because it remains visible without requiring extra interaction.
If the input enters an error or warning state, the helper text is replaced by the validation message to avoid confusion.
- Best practices
- Use sentence-style capitalisation.
- Write text as full sentences with appropriate punctuation.
- Keep both types of text brief and relevant to the user’s task.
- Avoid duplicating label content, each element should serve a distinct purpose.
Placeholder text
Optional placeholder text appears within an input field in lower contrast than user-entered text. It provides a hint or example of what to input, but disappears as soon as the user begins typing. Because of its transient nature, placeholder text must not be used as a substitute for a visible, persistent label, and it should never contain essential or instructional information.
In some cases, using a simple example, such as a sample email address or postcode, can be helpful to clarify expected formatting or content. However, this should only be done when it adds value and does not create dependency or confusion.
- Best practices for placeholder text
- Use sentence-style capitalisation, and in most cases, write the text as a direct statement without punctuation.
- Do not include critical or instructional content, only hints or examples.
- Avoid using placeholder text unless necessary; it can hinder usability, especially for users with cognitive impairments or when reviewing completed forms.
- Placeholder text is not shown by default and should be added intentionally, with careful consideration of its value.
Required vs optional
Form fields can be identified as either optional or required, depending on the context and complexity of the form. The Buckholt design system distinguishes between simple and complex forms to determine how required and optional fields should be communicated.
- Simple forms
Shorter, user-focused forms such as sign-up forms, contact forms, or checkout screens. These typically contain mostly required fields. - Complex forms
Longer, product-focused forms often used for data capture or configuring options. These forms usually contain more optional fields, with only a few required inputs.
When deciding how to label fields, consider the overall number and distribution of required versus optional fields across your product. Strive for consistency across all forms within the same product, or at a minimum, within the same form type.
- Field label guidance
- If most fields are required, label only the optional fields with (optional).
- If most fields are optional, label only the required fields with (required).
This approach reduces visual noise while ensuring users can clearly identify which fields are necessary to complete.
Form controls
Buckholt provides a range of form controls that enable users to input or select data. These controls are grouped into three interaction types.
|
Type
|
Overview
|
|---|---|
| Free-form inputs | Free-form inputs are commonly used where users need to enter custom text or numbers. They allow unrestricted input, such as letters, numbers, or symbols. Common free-form inputs include text inputs and text areas. |
| Selection controls | Selection controls present users with a predefined set of options to choose from. Typical examples include checkboxes, radio buttons, file uploaders, switches, and select lists (including combo boxes and multiselects). |
| Bound entry controls | Bound entry controls are designed for structured numeric input, such as dates, times, or values within a set range. These controls include number inputs, date pickers, and range components. |
States
The following states can be applied to form components, depending on context and user interaction.
|
State
|
When to use
|
|---|---|
| Resting | The default state of a component when it is visible and interactive, but not currently being interacted with. A resting input can be empty, contain placeholder text, or display user-generated content. |
| Active | A component is in an active state when the user is actively entering data, such as typing into a text field. |
| Focus | When a user navigates to a component, by clicking it or using the keyboard, it becomes focused. This visually indicates that the component is ready for interaction. |
| Error | This state is triggered when input is invalid, or a required field is left empty. Errors may also arise from system issues. Error states typically block form submission until the issue is resolved and must be clearly communicated to the user. |
| Disabled | The component is visible but not interactive. This state may be used when user access is restricted, or certain conditions aren’t yet met. Disabled components are excluded from keyboard navigation and do not need to meet WCAG contrast requirements. |
| Read-only | A read-only field displays content that cannot be edited by the user, but can still be focused, selected, and copied. This is useful for showing values that are generated by the system or locked for editing due to user roles or state. Read-only inputs maintain full accessibility and should still use clear labelling and semantic markup. |