This environment is not optimized for viewing on small or mobile devices. Please view on a larger browser for the best experience.

If you have any questions, please contact us.

Form Inputs

Our form elements are designed to help users complete forms efficiently and successfully. Review both element design and implementation guidelines to understand how to support the form experience through both development and front-end styling.

Best Practices

Review the following guidelines for optimal form design and development.

Form Labels & Input Fields

  1. Write clear and concise labels. Use simple and succinct labels that help the user understand what information is required at a glance.
  2. Stack labels vertically above input field to:
  • Allow the eye to scan the information more quickly.
  • Reduce cognitive load so the user does not struggle to connect the label and input.
  • Optimize design for mobile with full-width label and input.

Structure

  1. Use a single-column layout. Single-column layouts are easier to follow, understand, complete and submit.
  2. Clearly title your form so users understand exactly what they’ll achieve or receive once they submit it.
  3. Add progress bars or a multi-step process for long forms. Chunking information helps users process, understand and recall content. It also gives a clear indication of how much effort is required to complete the form.
  4. Group related fields together and provide clear section titles (e.g. Contact Information) and adequate spacing.

Action Buttons

  1. Make action buttons descriptive, giving the user a clear understanding of what will happen upon selecting it. Avoid generic labels such as “Submit” and “Send,” using instead labels that describe the action.
  2. Use the Default or Prominent button for the primary action and the Subtle or Ghost buttons for secondary actions.

Feedback

  1. Tooltips. Address possible user concerns with information tooltips. For example, why you need to collect specific information or how you will use that information.
  2. Error Messages. Craft error messages that do not blame the user. It should explain the issue at hand and provide clear, direct instructions on how to correct the error.
  3. Success Messages. Notify users of a successful completion of a form with a toast and next steps (if applicable).

Development Considerations

  1. Use inline form field validation. It should appear once a user has moved to the next field, not while the user is still working within a field.
  2. Use auto-fill browsers. Title each field with a common attribute that browsers will recognize to help speed up the form completion process for your visitor.
  3. Enable the ability to tab to next form field. Allow usage of the tab key on forms so users can move to the next form field without lifting their hands off a keyboard.
  4. Offer field focus. Auto-focus the first input field in your form. Auto-focusing a field gives the user an indication and a starting point, so that they can quickly start filling out the form. Thereafter, make the active input field prominent and focused.
  5. Provide matching keyboard for mobile users. Set HTML input types to show the correct keypad. Seven input types are relevant to form design:
input type=
Details
"text"
displays the mobile device’s normal keyboard
"email"
displays the normal keyboard and '@' and '.com'
"tel"
displays the numeric 0 to 9 keypad
"number"
displays a keyboard with numbers and symbols
"date"
displays the mobile device’s date selector
"datetime"
displays the mobile device’s date and time selector
"month"
displays the mobile device’s month and year selector

Implementation

There are many considerations that go into a well-designed form experience, beyond the styling of the elements. We’ve outlined some key areas to focus on to build a user-friendly form experience.

Validation Types

Inline

Inline validation shows the user in real time if an error has occurred while filling out a form. It may be an input error such as using an incorrect character or the field is required and was tabbed through. Using inline validation is preferred.

Best Practice

  • Errors should not appear before the user has finished completing the input.

  • Error messages should be removed dynamically once the user has corrected their mistake. Messaging should live-update on a keystroke level.

With Mistake

Corrected Mistake

Post-Validation

In post-validation, the form is checked for errors after the user selects to save or submit. The page reloads, and the same visual cues are used as with inline validation. In addition, an error alert is used. Inline validation and post-validation can be combined to show errors inline and then messaging after validation.

pre-Submission

Post-Submission

Error Messaging

Error messages appear after the label and before the input. A light red background is used to bring attention to the message, while a red border highlights the input.

See Alerts page for specifications on Error banners at the top of the page.

Anatomy
1) Alert Label
font-face: Helvetica Now Text
font-weight: 700
font-size: 16px
line-height: 20px
bottom-margin: 4px
color: Error Dark

Alert Label Mobile
font-size: 14px
line-height: 18px
2) Alert Icon
font-face: Font Awesome 6 Pro Light
font-size: 24px
color: Error Dark
code: exclamation-triangle (f071)
3) Alert Description
font-face: Helvetica Now Text
font-weight: 400
font-size: 16px
line-height: 20px
bottom-margin: 4px
color: gray 02

Alert Description Mobile
font-size: 14px
line-height: 18px
4) Alert Background
background-color: Error Background
border-radius: 4px
Size & Spacing

Focus State

For all inputs, the focus state is derived from the browser. We also change the input border color as outlined below.

Label
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Descriptions

Descriptions are used to provide additional instructions the user needs to complete the task. They should only be used when information is needed to prevent an error. Use Descriptions sparingly to prevent information overload within a form and keep them to a 100-character maximum.

The Description is placed before the input to provide necessary information before the user engages with the input, both for sighted users and those using screen readers. For screen readers to verbalize this information, the subordinate content must be nested within the label.

Note: Do not use placeholder text to provide information the user needs to execute the task.

Anatomy
1) Input Description (optional)
font-face: Helvetica Now Text
font-weight: 400
font-size: 16px
line-height: 20px
bottom-margin: 4px
color: gray 02

Input Description Mobile
font-size: 14px
line-height: 18px

Required Fields

It’s important to differentiate between required and optional fields. When using forms that contain mostly required fields, we recommend indicating which inputs are optional, rather than marking the required fields. Do not use an asterisk in the label to indicate mandatory fields—instead, write out “Optional” or “Required.”

To maintain consistency and set expectations for the user, select one approach to use within a single application.