Form component definition
A form is a group of related input controls that allows users to provide data or configure options. Forms are used for submitting data, and designers should consider each field and what value the data will provide.
form
18 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Form anatomy
A form consists of three main parts: (1) Header (optional) - provides title and description for additional context or instructions; (2) Form body - area where users provide information through various input fields, labels, and helper text; (3) Footer - provides actions allowing users to submit or cancel the data entered.
Default form style spacing
Default forms use a traditional style where labels are positioned outside and above the input field. Default forms can use three input field sizes: small (32px), medium (40px), or large (48px). Form inputs are equally stacked with 32px/2rem padding separating each component. Default forms use the wide gutter mode.
Fluid form style spacing
Fluid forms use an alternative input style where the label is placed inside the input field and aligned with the user input text. Fluid inputs have only one size at a height of 64px. Form inputs are stacked flush to one another with 0px of padding between them. Fluid forms use the condensed grid and can hang into the gutter without causing label misalignment.
Form alignment with grid
Default form inputs and labels should align flush to grid columns using the wide gutter mode, prioritizing vertical label alignment. Do not hang default inputs into grid gutters as this will cause labels to misalign. Fluid forms should stack flush with no spacing using the condensed gutter mode and remain a cohesive architectural unit.
Two-column form spacing
In two-column forms, columns should be proportional and align to grid columns when possible. Default forms use the wide gutter mode with 32px padding between form columns. Fluid forms use the condensed gutter mode with 1px padding. When one column item becomes invalid and grows to accommodate an error message, the accompanying column item will also grow to account for the needed space.
Form vertical spacing recommendation
The typical recommended vertical spacing between components in a form is 32px.
Form label best practices
Labels should follow these best practices: (1) Use sentence-style capitalization for all labels except for product names and proper nouns; (2) Keep the label short and concise; (3) Do not use colons after label names. Text fields should always have a label, except in rare instances where context negates the need, which requires consultation with an accessibility expert.
Form default values best practice
Where possible, add programmatic assistance by detecting and pre-filling inputs to reduce errors and save time. When the software cannot determine the value, use type-ahead to make suggestions. Use sentence-case for default values, detected values, and auto-completion text.
Helper text in forms
Optional helper text is pertinent information that assists users in correctly completing a field. Helper text should always be available when the input is focused and is often used to explain the correct data format. Helper text appears as persistent text under a default input. Helper text is not available in fluid inputs, which use tooltips instead. Helper text should use sentence-style capitalization and in most cases be written as full sentences with punctuation. When helper text is used, it is replaced by an error or warning message if a state change occurs.
Tooltip help in forms
Tooltips can be added inline with a form label if additional non-pertinent information is needed to assist users, such as context setting. Tooltip content may include in-depth information about the field or options, and links to additional information. In situations where complex instructions would be appropriate, tooltips can be used in addition to helper text. However, all pertinent assistive information for form completion—such as format content—should be presented as helper text under the field, not in a tooltip.
Tooltip help in fluid forms
Fluid inputs are an exception to the no critical information in tooltips rule. Due to their architectural nature, fluid inputs do not provide space under the field for helper text. All assistive text, whether pertinent or additional, is provided through a tooltip when using fluid inputs.
Placeholder text in forms best practices
Optional placeholder text appears inside an input field at lower contrast and provides hints or examples of what to enter. It disappears after the user begins entering data and should not replace a persistent label nor contain crucial information. Best practices: (1) Use sentence-style capitalization as a direct statement without punctuation; (2) Placeholder text is not required and by default not shown; (3) It should only be added when necessary as it can be harmful to user interactions.
Required versus optional field labeling
The labeling of required versus optional fields depends on form complexity. In simple forms (shorter, user/consumer-oriented like sign-up or checkout), most fields tend to be required. In complex forms (longer, product-oriented for Enterprise software configuration), most fields tend to be optional. The pattern should be consistent throughout a product: if the majority are required, mark only optional fields with '(optional)'; if the majority are optional, mark only required fields with '(required)'.
Form input component types
Carbon provides three types of data input components: (1) Free form inputs - allow users to enter any configuration of letters or numbers; common examples include text input and text area; (2) Selection controls - offer users a selection from pre-determined options; common examples include checkboxes, radio buttons, file uploaders, toggles, combo box, and multiselect; (3) Bound entry controls - allow numeric data input like dates and times and may restrict user input to a certain range; common examples include number input, date picker, and slider.
Form component states
Form components have the following states: (1) Enabled - when a text input is live but not directly interacted with (default/normal state); can contain no content, placeholder text, or user-generated content; (2) Active - when a user is actively typing into the field; (3) Focus - when a user tabs to or clicks on the input, indicating successful navigation; (4) Error - when user input is invalid, required field not filled, or system error; requires user response before submission; (5) Warning - calls attention to an exception condition that might not be an error but could cause problems; (6) Disabled - when user is not allowed to interact due to permissions, dependencies, or prerequisites; removes interactive function and styling not subject to WCAG contrast compliance; (7) Skeleton - indicates on initial page load that the input has not yet fully loaded; (8) Read-only - coming soon.
Form AI presence overview
Form has a modification that takes on AI visual styling when AI is present. AI variants function the same as normal variants except for the addition of an AI label, which is both a visual indicator and the trigger for the explainability popover. AI presence in form can appear broadly over the whole form to indicate AI is present in all aspects, or focused on certain parts if only limited form content is generated by AI. Only those AI-generated components should receive AI presence styling, not the entire form.
Narrow gutter mode not typically used in forms
The narrow gutter mode (16px) is typically not used in forms as it often places the text in the gutter.