Text input

On this page

Example

Designer guidance

Developer guidance

Content editor guidance

Accessibility 

Support

Anatomy

States

Designer Guidance

When to use

Use the text input component when users need to:

• Enter a single line of text.
• Enter short responses such as names, email addresses, phone numbers, or reference numbers.

When not to use

Avoid using a text input component when:

• Users need to enter multiple lines of text: use a Text area component instead.
• Users need to select from predefined options: consider using a Select input, Radio button, or Checkbox component.
• Users need to enter a date: use the Date input component instead.

How to use

• Labels: Always provide a visible label above the input. Use sentence case and make it clear what data is expected.
• Help text: Use help text below the label to add additional context where needed. (e.g. the expected format for passwords, postcodes or emails.)
• Placeholder text: Do not use placeholders as a substitute for labels or help text. Placeholders disappear when typing and may not be read by assistive technologies.
• Copy and paste: Do not block copy/paste functionality.
• Spellcheck: Disable spellcheck for fields where it is not appropriate (e.g. passwords or postcodes.)

Behaviours

• Error messages appear below the text input when validation fails.
• Error messages must:
  • Be clear, concise and written in plain English.
  • Explain what went wrong and how to fix it.
• Avoid vague messages such as ‘An error occurred’. An error for a specific situation is more helpful.
• Do not apologise. It does not help the user resolve the problem.
• Frequency of errors should be tracked to help with testing and research.
• Focus state must be clearly visible.
• Disabled text inputs:
  • Indicate that the field exists, but is unavailable.
  • Must not accept input or be submitted.
  • Should display a "not-allowed" cursor on hover.
• Required fields must be clearly indicated using text (e.g “Required”) or an asterisk with supporting context.
  • Do not rely on colour alone to show required or error states.

Options

The text input has optional help text:

Use the help text to:

• Provide guidance relevant to most users.
• Give an example that clarifies what information is expected.

Help text should:

• Be no longer than a single short sentence.
• Not be used for long and complex instructions.

Developer Guidance

Best practices

• Use semantic HTML. 
• Programmatically associate labels with inputs.
• Use <aria-describedby> for help text and error messages.
• Use <aria-required="true"> for required fields.
• Do not rely on placeholder text for instructions.
• Ensure keyboard operability and logical focus order.
• Apply visible focus styles and maintain minimum target size (44×44px).

Content Editor Guidance

Best practices

• Write labels that are short, clear, and descriptive (e.g. “Email address”).
• Use sentence case without punctuation.
• Provide help text separately if needed (not as placeholder).
• Avoid jargon or ambiguous terms.

Accessibility

Accessible text input fields must:

• Always use a visible label for each input.
• Do not use placeholder text as a substitute for labels.
• Provide additional instructions using <aria-describedby> when necessary.
• Required fields must be communicated to all users:
  • Visual: Clear text indicator (e.g “Required or asterisk”).
  • Programmatic: <aria-required="true">.
• Ensure sufficient colour contrast for text and borders.
• Inputs must be operable via keyboard and have visible focus indicators.

WCAG success criteria

• 1.3.1 Info and Relationships (Level A)
  Labels programmatically associated with inputs.
• 1.4.3 Contrast (Minimum) (Level AA):
  Text and borders meet contrast requirements.
• 2.1.1 Keyboard (Level A):
  Fully operable via keyboard.
• 2.4.6 Headings and Labels (AA):
  Labels describe purpose clearly.
• 3.3.2 Labels or Instructions (A):
  Provide clear instructions for input and indicate required fields before submission.

Related components

Text area

Text input