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:

Disabled

Attributes:

• No tab stop - Not focusable

Use Case:
This is an intermediate state while the form is being submitted, and would only ever be used if that state is shown in the prototype. It is generally not recommended to use this state for designs.

Read-only

Attributes:

• Tab stop - Focusable

Use Case:
When presenting the selection in a previously submitted form. Users with screen readers can listen to this information.

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. 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
   24 characters or less – The label should be clear and to the point.

2. In-line Messaging (optional)
   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
   Error messages need to explain in a concise manner exactly what the user has done wrong, and how they can fix it.

Icon Usage

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