component

Forms

USAJOBS adds or clarifies design for labels, contextual help, required/optional field handling, and legend.

Design Complete

Contextual Help

Contextual help provides assistance in clarifying the intent of a question or form input.

Brief help

Some concise help text that explains the intent of the form input.

Usability

When to use
  • A concise explanation of the intent of the question or data being requested can be provided without the need for deeper explanation.
  • As a replacement for placeholder text in order to provide an example of the type of data being requested.
When to consider something else
  • When a more detailed explanation is needed.
  • When you want to provide supporting documentation or policy.
Guidance
  • Help text must not begin with a "-" (dash) or other punctuation.
Detailed Help
Extended help
Make an inspiring Opportunity by including…
  • Why is this important?
  • What does success look like?
  • Who will benefit?
  • How does this fit into the bigger picture?
Outside help - DEPRECATED

Usability

When to use
  • A detailed explanation of the data being requested is necessary.
  • Additional context for why the request is being made is desired.
When to consider something else
  • A more detailed explanation is not necessary.

Our dropdown adds protection from the text running into the dropdown arrow. We also have adopted the select2 plugin for long dropdown menus.

Single select
Multi select

Usability

When to use
  • Use the chosen plugin when there are more than 25 options in a dropdown.
When to consider something else
  • When the select menu is 25 items or less use of the chosen plugin is not necessary.

Disabled

Guidance and styling on disabled and readonly inputs and select elements.

Disabled
Read only

Labels

Labels are simple text descriptions of data being requested and are found in close proximity to a form input that requests that data.

Usability

Guidance
  • Labels are concise text that describes the data being requested by a form input.
  • Labels should appear directly above form controls as seen in the U.S. Web Design Standards.
  • Labels do NOT end in a colon.
Required/Optional Field Indicator

Usability

The US Standards have been updated to only indicate optional fields and we will be following their guidance.

When to use
  • To identify optional fields only.
When to consider something else
  • If all fields are required consider the form legend to communicate that to the user.

Legends

There are two types of legends: Form and fieldset.

.usajobs-form__legend

[Form Title]

All fields are required
.usajobs-fieldset legend
Email and password
Telephone

Form legend

When to use
  • When all fields for a form are required use the text "All fields are required".
  • When all fields for a form are optional use the text "All fields are optional".
  • When most of the form fields are required use the text "All fields are required unless otherwise noted" in conjunction with the Optional Field Indicator to indicate the optional fields.
When not to use form legend
  • The form legend may be omitted in cases where the form is extremely short or the fields are obviously required. For example, a form that consists of one checkbox or a sign in form.
Guidance
  • The form title is often long enough to cause a collision with the legend, thus it was moved to be on the line below the form title.

Fieldset legend

When to use
  • When multiple fieldsets are in use within a form.

Validation

Styling, timing, and alert style guidance.

Visual

Labels

  • When a field is required the help text "This field is required" should be placed directly under the field label or required question.
  • The help text related to character issues or unmet requirements should use the text "This field" rather than the actual field name.

Timing

Errors
  • Inline error validation should occur on all required input fields and dropdowns. The error styling should be triggered after the field has lost focus (the user has clicked or tabbed away from the input field without meeting field requirements).
  • Do not display an alert at the top of the page when using inline error validation.
  • Inline error validation should also occur if a user enters a character that does not meet the requirements of the field. For example, entering a number in the first name text input. This should occur for optional and required fields.
Success
  • Success styling should be triggered when a form error (red styling) is corrected. The success validation should appear once the user clicks or tabs out of the input and meets the basic requirements of that field.
  • Success styling should be removed when the page is saved.
Dependent fields
  • When you have dependent fields (i.e. Start Date & End date) you should not receive an error on either field until the user leaves the set (both fields). After the set has been left, error styling should be triggered on one or both of the fields.

Error alert

  • If a user saves a form with known errors or skipped required fields, reload the page with the errors styling displayed and an alert at the top of the page.
  • The alert should appear above the form but not within the form.
  • The alert should read "We can’t save your information because there are one or more errors. Please correct the information below and then save your changes."

Alternative Layouts

Horizontal layout

Save search

Horizontal layout with validation error -- Left

Save search

This field is required
Horizontal layout with validation error -- Right

Save search

This field is required

Usability

When to use
  • Use this layout sparingly as the standard error handling was not designed to be used in side-by-side columns. Our only current approved use is in Saved search which is depicted above.

Reveal fields

Selecting certain form elements can reveal additional elements. This allows for hiding complexity from users that don't need to see it.

Reveal hidden form fields

May we contact your supervisor? (optional)

Usability

When to use
  • Use this pattern to reveal form fields based on user input.