# Choosing a form field

Pick the field that matches the data you are collecting, and the number of options the user is choosing from.

Section: patterns
Docs: https://nebula.kaluza.com/patterns/choosing-a-form-field

---

## Overview

The right field usually follows from what you're collecting. The decision only gets interesting when the user is choosing from a set of options.

This pattern covers which field to use. Each field's own page covers how to use it, and [Forms](/patterns/forms) covers how to structure the form around it.

## The core decision

Start with whether the value comes from a known list of options, then work down.

### Where the value isn't from a known list

- **Is it a specific type of input, such as a number, an amount of money, an email address, a date or a file?**
  - **Yes.** Use the field for that type.
  - **No.** Will the answer run to more than one line?
    - **Yes.** Use [Textarea Field](/components/textarea-field).
    - **No.** Use [Text Field](/components/text-field).

### Where the value comes from a known list

- **Can more than one option be selected?**
  - **Yes.** Up to about six options, use [Checkbox Field](/components/checkbox-field). More than that, use [Combobox Field](/components/combobox-field) with `multiple` set.
  - **No.** Up to about six options, use [Radio Field](/components/radio-field). About seven to fifteen, use [Select Field](/components/select-field). More than that, or wherever the user needs to search, use [Combobox Field](/components/combobox-field).

## Principles

### Use the most specific field for the data

Where a field exists for the thing you're collecting, use it rather than a plain Text Field. The specialised variants set the input's type, so a phone number brings up a keypad on a phone and a password is masked as it's typed. A Text Field labelled 'Email' does none of that.

### Don't use a field to display a value

If a value is read-only, render it as text rather than putting it in a field, and use [Summary List](/components/summary-list) where it belongs in a set of labelled values.

### Show all the options when there are few

A short list of options is faster to scan when every option is visible, which is why the count matters more than the kind of data. Hiding four options behind a Select Field costs the user an interaction to see something that would have fitted on the page.

## Scenarios

### A specific type of input

Use the field built for it rather than a Text Field with a telling label:

- **A number**: [NumberField](/components/subcomponents)
- **An email address**: [EmailField](/components/subcomponents)
- **A telephone number**: [TelField](/components/subcomponents)
- **A password**: [PasswordField](/components/subcomponents), which masks characters as the user types
- **An amount of money**: [Currency Field](/components/currency-field), which prefixes the currency symbol
- **A date**: [Datepicker Field](/components/datepicker-field)
- **A month and year**: [Monthpicker Field](/components/monthpicker-field)
- **A file**: File Field, which is for adding files rather than choosing from ones that already exist

The first four share the Text Field API. See [Text Field](/components/text-field).

```tsx
<Stack spaceBetween={4}>
  <NumberField id="meter-reading" label="Meter reading" characters={8} />
  <EmailField id="account-email" label="Email address" characters={25} />
  <CurrencyField id="payment-amount" label="Payment amount" characters={8} />
</Stack>
```

Datepicker Field covers dates the user knows from memory too, such as a date of birth. Its input takes a typed `dd/mm/yyyy` date without the calendar being opened, so nobody has to page back through years. [Date Field](/components/date-field), which split the date into three inputs for that case, is deprecated for new work.

### More than one line of text

Use [Textarea Field](/components/textarea-field). A single short value like a name or a reference number belongs in a Text Field, even where the field looks wide enough for more.

```tsx
<TextareaField id="call-notes" label="Notes from this call" />
```

### Plain text

Use [Text Field](/components/text-field), where none of the specialised variants fits and the answer is a single line.

```tsx
<TextField id="account-reference" label="Account reference" characters={12} />
```

### Several options from a list

Use [Checkbox Field](/components/checkbox-field) where the user can pick any number of options from a short list, and a single Checkbox inside it for one on or off choice.

```tsx
<CheckboxField label="Which services does the account have?">
  <Checkbox label="Electricity" id="service-electricity" />
  <Checkbox label="Gas" id="service-gas" />
  <Checkbox label="Boiler cover" id="service-boiler" />
</CheckboxField>
```

Once the list is long enough that the user would rather search it than read it, use [Combobox Field](/components/combobox-field) with `multiple` set, which shows each selection as a removable chip.

### One option from a list

Use [Radio Field](/components/radio-field) for up to about six options, where every option can be read at once.

```tsx
<RadioField
  name="contact-preference"
  label="How should we contact you?"
  defaultValue="email"
>
  <Radio label="Email" id="contact-email" value="email" />
  <Radio label="Phone" id="contact-phone" value="phone" />
  <Radio label="Post" id="contact-post" value="post" />
</RadioField>
```

From about seven options, use [Select Field](/components/select-field). Past about fifteen, or wherever the user would rather search than scroll, use [Combobox Field](/components/combobox-field), which handles single selection as well as multiple.

A Radio Field with a single option is never right, because a radio can't be deselected once chosen. For a single yes or no, use a Checkbox.

## Accessibility

- **Every field needs a visible label**, whichever you choose, and a placeholder is not one. See [Forms](/patterns/forms#labels-and-hints).
- **A group of radios or checkboxes is one field.** Radio Field and Checkbox Field wrap the group so it's announced as a whole rather than as loose controls.
- **A single radio traps the user**, because it can't be deselected once chosen. Use a Checkbox for a binary choice.
- **No field has a disabled state**, which is deliberate. See [Disabled states](/patterns/forms#disabled-states).
- **Give every field a unique id**, since each one associates its label by id, and a repeated id breaks that association for both fields.

## Related

- [Forms](/patterns/forms)
- [Text Field](/components/text-field)
- [Textarea Field](/components/textarea-field)
- [Select Field](/components/select-field)
- [Combobox Field](/components/combobox-field)
- [Radio Field](/components/radio-field)
- [Checkbox Field](/components/checkbox-field)
- [Datepicker Field](/components/datepicker-field)