in development

Textarea

Description

The <textarea> element is used for multi-line text input, making it ideal for comments, messages, or other longer user inputs. Unlike the <input> element, which is limited to a single line, <textarea> allows users to input and edit text over multiple lines.

A <label> should always accompany a <textarea> to ensure accessibility and clarity. The label is typically positioned above the field and follows the standard label styling of our design system.

Use Cases

• When the user needs to enter long-form content like messages, comments, or descriptions.
• When the input may span multiple sentences or paragraphs (e.g., feedback, support requests).
• When formatting or line breaks matter for clarity or meaning (e.g., addresses, code snippets).
• When the field supports creative or open-ended input (e.g. notes).
• When a richer text editing experience is needed, such as markdown or WYSIWYG support.

Usage

Default Height: Provide enough space for users to see what they’re typing (e.g., 3–5 lines tall).

Auto-Expand: Consider dynamically increasing the field height as the user types instead of using a scrollbar.

Max Height: If auto-expanding, limit the maximum height and introduce a scrollbar for very long text.

Resizing: By default, <textarea> elements are resizable by users. Consider restricting resizing only vertically (resize: vertical;) to prevent breaking layouts.

Input Types: Always use <textarea> for multi-line input instead of <input type="text">. If specific formatting is required (e.g., Markdown, HTML, or rich text), provide a toolbar or formatting help.

Use clear and descriptive labels: Each <textarea> should have an associated <label> describing its purpose. The for attribute of the <label> must match the id of the <textarea> to ensure compatibility with screen readers.

Define appropriate sizing: Set a sensible rows and cols value or use CSS for flexible resizing while avoiding excessively small or large default sizes.

Avoid using placeholders as labels: Since placeholder text remains visible until the user starts typing, it should not replace a proper <label>. Instead, use it to provide hints or examples of expected input.

Ensure visible focus indicators: The focus state of the <textarea> should be clearly visible for users navigating via keyboard.

Error identification: If validation is required, indicate errors using aria-invalid="true" and provide a helpful error message linked with aria-describedby.

Support resizing appropriately: By default, <textarea> elements are resizable. Ensure resizing does not break layouts or cause usability issues. Use resize: none; in CSS if resizing should be disabled.

Contrast and readability: Maintain proper contrast between text, background, and borders to ensure readability.

Provide accessible instructions: If a specific format or length limit is required, use help text or aria-describedby to communicate these requirements.

Formating: Only offer formatting when it’s essential for the task. When users are given rich text formatting options (e.g., bold, italics, headings), it can lead to inconsistent or messy input, especially if the content is meant to be consumed in a uniform way. Formatting also adds complexity to both the user interface and the data handling on the backend, increasing development and maintenance effort.

Spellcheck: Use spellcheck="true" for fields that require proper spelling (e.g., messages, feedback). Disable spellcheck (spellcheck="false") for code snippets or special formats.

Character Count:
If there's a character limit, show the remaining count (e.g., “250/500 characters left”). Only enforce limits where necessary (e.g., SMS messages, form fields with strict constraints). The character limit for a text area should always depend on the purpose of the input, but should never be more than 2000 characters because of security concerns.

Example

<textarea>

Textarea with label

The label

Textarea with error

Please fill this field

Resources

• textarea in Figma