Skip to content
Design System

Text field

Text fields allow users to input custom text entries with a keyboard. Various options can be shown with the field to communicate the input requirements. Always use a label and associate the label to the field properly.

Code

Stacked layout

Labels can be placed either on top or on the side. Top labels are the default and are recommended because they work better with long copy, localization, and responsive layouts.

Help or instructional text goes here 
<div class="form-group form-group--stacked">
  <label for="textinput" class="form-label"> … </label>
  <span class="help-block">
    <span class="help-block__text"> … </span>
    <span class="help-block__link"> … </span>
    <!-- optional warning message -->
    <div class="text-warning d-flex align-items-center space-x space-x-3">
      <svg class="icon icon-16" aria-hidden="true">
        <use xlink:href="/assets/svg/solid.svg#bell-on"></use>
      </svg>
      …
    </div>
    <!-- /optional warning message -->
  </span>
  <!-- error handling -->
  <div class="form-error" role="alert">…</div>
  <!-- /error handling -->
  <input type="text" id="" value="" placeholder="Placeholder" class="form-control" />
</div>

Horizontal layout

Side labels are most useful when vertical space is limited.

(Required)
Help or instructional text goes here 
<div class="form-group row">
  <div class="col-sm-3 col-md-2 d-md-flex text-md-right flex-column align-items-end">
    <label class="col-form-label" for="text-field">…</label>
    <span class="help-inline">(Required)</span>
  </div>
  <div class="col-sm-9 col-md-10 input-width--md">
    <input class="form-control" id="text-field" required="true" type="text" placeholder="Placeholder" />
    <!-- error handling -->
    <div class="form-error" role="alert">…</div>
    <!-- /error handling -->
    <span class="help-block">
      <span class="help-block__text"> … </span>
      <!-- optional warning message -->
      <div class="text-warning d-flex align-items-center space-x space-x-3">
        <svg class="icon icon-16" aria-hidden="true">
          <use xlink:href="/assets/svg/solid.svg#bell-on"></use>
        </svg>
        …
      </div>
      <!-- /optional warning message -->
    </span>
  </div>
</div>

Input sizes

<input class="form-control" id="" type="text" placeholder="Placeholder">

In Practice

Text fields should:

  • Be clearly labeled so it’s obvious to users what they should enter into the field
  • Be labeled as “Optional” when:
    • You need to request input that’s not required
    • And there are less optional fields than required
  • Be labeled as “Required” when:
    • You need to request input that’s required
    • And there are less required fields than optional
  • Only ask for information that’s really needed

Content guidelines

Labels

  • For helper text provide an example or specific syntax for the input, rather than in the input area, so that it’s visible after text has been entered. Only use this where clarification is required, and try not to overuse it.
  • Field label text should be short, concise, and, when possible, in noun form. For example “Name”.
    • Edge case: When a text field isn’t part of a form and is placed individually on a page (like a comment field), then you can write the field label as a call to action. For example, “Leave a comment”. This is because there’s no surrounding context and using “Comment” alone could be confusing.

Help text

Help text provides extra guidance or instructions to people filling out a form field. It can also be used to clarify how the information will be used.

Use help text:

  • When the text field label doesn’t clearly explain the purpose of the text input
  • To provide guidance or instructions on the type of information needed
  • To show examples of the required format for modeled text inputs

Best practices:

  • Avoid repeating the field label. If the field label provides sufficient context for completing the action, then you likely don’t need to add help text.
  • If there’s not enough room to include both instructions and an example, then only include the example.

Accessibility

Structure

  • Screen readers convey information about text fields automatically through native HTML.
    • To disable, add the HTML disabled attribute to the text field.
    • To set as read-only, add the HTML readonly attribute to the text field.
    • Provide a unique id attribute value for the text field and use the for attribute to connect the label with the text field. This allows screen readers to convey the purpose of the text field.

Labeling

  • Make sure all fields have a visible label and the label is associated properly to the field for accessibility.
  • Avoid using placeholder text whenever possible. It can pose a range of accessibility problems, like:
    • Low color contrast, making the text hard to read
    • Inconsistent behavior between browsers and screen readers
    • Text disappearing when the user starts typing, which can be confusing to people with cognitive impairments
  • Limited space available for additional context, due to field size
  • Make sure any critical information is communicated either in the field label or using helper text. Search fields or brief examples are the only exceptions where placeholder text is OK.

Keyboard support

  • Text fields have standard keyboard support.
  • Users who rely on the keyboard expect to move focus to each text field using the tab key (or shift + tab when tabbing backwards)
  • If the type is set to number, then users can use the up and down arrow keys to adjust the value typed into the field when hovering over or focusing the field to make the arrows appear
  • Using the disabled attribute will prevent the text field from receive keyboard focus or inputs
  • The readOnly attribute allows focus on the text field but prevents input or editing

Design resources

View component in Figma