Text area

On this page

Anatomy

States

Designer guidance

Developer guidance

Content editor guidance

Accessibility 

Support

Related components

Anatomy

States

Designer Guidance

When to use

Use a text area component when users need to enter multiple lines of text such as:

• Comments or feedback.
• Descriptions.
• Explanations or supporting information.

When not to use

• For single-line text: use Text input component instead.
• When users must select from predefined options: use Select, Checkbox, or Radio components.
• For complex open ended questions: consider breaking down your question into smaller inputs or structured options.

How to use

Labels

• Always include a visible label above the field. 
• Use sentence case 
• Make it clear from the label what information is expected.

Help text

•  Place help text below the label.
• Keep it short and relevant to most users.
• Use it to clarify what to enter or provide a brief example.

Placeholder text

• Do not rely on placeholder text for instructions.
• Do not use placeholder text as a label substitute.
• Remember placeholders are not reliably announced by assistive technologies.

Copy and paste

•  Do not block copying or pasting. Users may rely on assistive tools or external documents.

Resizing 

• Allow users to resize the text area unless you have a strong, user tested reason to fix the size.
• Ensure resizing does not break the page layout or cause the content to overlap.

Behaviours

• Error messages appear below the text area when validation fails.
• Error messages must:
  • Be clear and specific
  • Explain what went wrong
  • Explain how to fix it.
  • Avoid vague wording such as ‘An error occurred’
  • Not include apologies. It does not help the user resolve the problem.
• Track frequency of errors to help with testing and research.
• Focus state must be clearly visible.
• Disabled text areas:
  • 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:
•  Clearly indicate required fields using text (e.g “Required”) or an asterisk with supporting context.
• Do not rely on colour alone to show required or error states.

Options

Help text -The text area can include optional help text

Size variants - Choose a size variant based on expected input length:

• Medium text area: Contains five lines of text before scrolling or resizing.
• Large text area: Contains seven lines of text before scrolling or resizing.

Developer Guidance

Implementation

• Use semantic HTML (<textarea>). 
• Programmatically associate labels with inputs.
• Use <aria-describedby> for additional instructions or 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).

Error handling

• Ensure error messages are programmatically linked using <aria-describedby>.
• Apply error styles in a consistent manner.
• Do not remove or override native browser validation messages without providing an accessible alternative.

Content Editor Guidance

Best practices

• Use short, clear, descriptive labels (e.g “Additional comments”).
• Use sentence case without punctuation.
• Provide help text separately if needed (not as placeholder).
• Avoid jargon or ambiguous terms.
• Keep instructions concise and actionable.

Accessibility

Text areas must:

• Always include a visible label.
• Never rely on placeholder text as a substitute for labels.
• Provide additional instructions using <aria-describedby> when necessary.
• Communicated requires status to all users:
  • Visual: Clear text  or indicator (e.g “Required" or asterisk).
  • Programmatic: <aria-required="true">.
• Ensure sufficient colour contrast for text and borders.
• Be fully operable via keyboard with have visible focus indicators.
• Avoid relying on colour alone to convey error or required states.

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 input

Checkboxes

Radio buttons