forms

Form workflow guidelines

• Warn user of something wrong only after they have had a chance to fill out the field.
• Mark as few input fields as possible as required.
  • If the form has mostly required fields, only mark the optional ones by using optional, and 'requiredNoLabel' on the required fields.
• Submit button has state='inactive' until the form is valid and ready to be submitted. (Still clickable)
• Only after (inactive) submit button has been clicked are any fields marked in red with state='alert'
• If the field can display feedback at any point, pass an empty string to it feedback='' to allocate space before displaying the feedback message, to avoid jumping when toggling the message on/off.

Frank fills out a form

Required / Optional labels

Use required prop to make an Input required.

If your form contains more required than optional fields, you can mark the optional fields instead, making it easier for the user to scan the form.

By using the optional prop, the text (optional) will be rendered after the label. Use in the same form as inputs with requiredNoLabel. This is supported by:

• <Input>
• <TextArea>
• <DatePicker>
• <Select>
• <FieldGroup> (text only, no need for requiredNoLabel)
• <Label> (also text only)

Group inputs with fieldset

Wrap related fields in a <fieldset> element and supply a header with <legend>.

<fieldset>
  <legend>Personal info</legend>
  <div className="bf-autocol">
    <Input label="First name" />
    <Input label="Last name" />
    <Input label="E-mail" />
  </div>
</fieldset>
<fieldset>
  <legend>Personal info</legend>
  <div className="bf-autocol">
    <Input label="First name" />
    <Input label="Last name" />
    <Input label="E-mail" />
  </div>
</fieldset>

Label for button groups

When grouping a set of checkboxes or radio buttons (or <Button.Group>) each item will have its own label and they should be grouped (semantically, and for accessibility) using <fieldset> and the whole fieldset group labelled using <legend className='bf-label'>.

<fieldset class="bf-fieldset">
  <legend class="bf-label">Legend text styled as label</legend>
  [radio buttons, set of checkboxes, or button group]
</fieldset>
<fieldset class="bf-fieldset">
  <legend class="bf-label">Legend text styled as label</legend>
  [radio buttons, set of checkboxes, or button group]
</fieldset>

In the example below, "Hǫfuð" is the <label> and "Choose your weapon" is the fieldset <legend> styled as a label.

Field instructions

When designing forms, labels, descriptions, and placeholders serve different purposes and are used to guide users and clarify expected inputs to increase usability and accessibility.

Label

A label is a descriptive text associated with an input field. Labels are always visible, providing clear guidance on the expected input. They are crucial for both user experience and accessibility, as they help users understand what information to enter. Labels should not be too short or vague, and they should always remain visible to maintain an intuitive interface.

The examples below show how labels alone can guide users. While Username and Email Address fields are often intuitive, labels like Location may need more context. Additionally, including a date format in a DatePicker can make it long, so consider adding a description for clarity.

Description

A description is additional information that complements the label, offering further guidance such as instructions, format requirements, or examples. They appear beneath labels and provide users with detailed information to ensure accurate input. Descriptions should be concise and clear to avoid confusion.

The examples below illustrate how descriptions can enhance labels by providing additional context. This helps users understand what is expected without making the labels too long or detailed.

Placeholder

A placeholder provides a short, temporary text inside the input field, disappearing when the user starts typing. They should never replace labels or descriptions because:

• They disappear on focus, reducing their capacity for guidance.

• They are not accessible for all users, especially those relying on screen readers.

• They are unnecessary when the format is intuitive. However, if used to complement labels, they can create a cleaner look when applied consistently to all fields.

  • Consider using “e.g.” when the expected format is unclear or varies, such as a postal code.
  • Avoid using “e.g.” when the expected format is clear and intuitive, such as an email address.

The examples below show how placeholders are added to complement the labels and descriptions. They provide a sample value or format, which can help users better understand what is expected in each field. It's important to remember that placeholders should never replace labels or descriptions, as they disappear when the field is active.