---
title: "Textarea — Usage"
canonical: https://sky-ui.cf.sky.com/components/textarea/usage
---

# Textarea — Usage

## Basic Guidelines

- Only ask what is really required – consider why you are requesting certain information and how it will be used. Any extra field in a form will affect its conversion rate.

- Order form fields logically from the user’s perspective and group related information.

- Do not present information that cannot be changed as a form field. Information which has already been submitted, should be displayed as regular copy instead.

**Labels** tell the user the purpose of the field and therefore make the UI more accessible.

**In-line Messaging** is an optional text field that can be used for further information, clarifying the required input, for example reasoning why the question is being asked, or what will happen with the information given.

**Validation** Messages inform the users if there has been an error within the input. Messages need to be clear, precise and constructive.

## Variants Usage

### Error Variant

**Form fields are validated on submit**, which means the form is either sent without issues, or updated showing an error. If errors are rectified, the form needs to be submitted again to trigger another validation. If everything is ok, the form is submitted and it’s not necessary to display a success state.

There are two ways an error can occur:

- The field is required but was left blank before submitting
- The input information did not reach validation.

The error message will be displayed directly beneath the input field.

### Mandatory Fields

Any textarea can be set to be mandatory. An asterisk will be displayed in front of the label. Please make sure that the meaning of the asterisk is explained to the user at the top of the form. It is not necessary to mark fields as optional.

  

### Disabled and Read-only – What’s the difference?

Visually the Diasbled and Read-only input fields look exactly the same, but their properties in the final product will differ. Here is a quick comparison:

## Alignment

Form fields should be stacked vertically in one column for an easy flow through the form.

The 32px gap is space saving, while still providing enough space between the fields to display the labels.

The Textarea component must align with the grid system set out in [Foundations](/foundations/containers/). It sits in-line with the rest of the text.

In a 12-column grid layout, the text input fields sit left-aligned within the six centre columns of the grid, in-line with the rest of the text. Their width should be based on the content they’re expected to receive.

The example below is downscaled proportionally for illustration purposes.

## Content Guidance

It is recommended to limit character lengths to avoid text being truncated.
Labels should always be clear and to the point.

1. **Label**<br/>24 characters or less – The label should be clear and to the point.

2. **In-line Messaging (optional)**<br/>In-line messaging should be as concise as possible, whilst still providing the user with any relevant information that could help them fill out the form field.

3. **Validation Message**<br/>Error messages need to explain in a concise manner exactly what the user has done wrong, and how they can fix it.

    Do keep your labels short and to the point.
  
    Do not write needlessly long labels to avoid them becoming truncated.

## Icon Usage

We do not recommended to use other [Icons](/components/icon/) within the Textarea, as they don’t provide any functionality, and often only add to a user’s cognitive load.