Skip to contentSkip to navigationSkip to topbar
Figma
Star

Textarea

Version 10.1.1GithubStorybook

A Textarea is a form element that allows users to enter text on multiple lines.

Component preview theme
<>
<Label htmlFor="message" required>Message (at least 120 characters)</Label>
<TextArea onChange={()=>{}} aria-describedby="message_help_text" id="message" name="message" required />
<HelpText id="message_help_text">Enter at least 120 characters</HelpText>
</>

Guidelines

Guidelines page anchor

A Textarea allows users to enter text on multiple lines. It is used with the Label and Help Text components.

A Textarea allows for any text to be entered and can't be restricted as other inputs can.

Accessibility

Accessibility page anchor
  • Include a visible label on all form fields.
  • Each label must use the htmlFor prop that equals the id of the associated textarea.
  • Avoid placeholder text. It's not broadly supported by assistive technologies, doesn't display in older browsers, and dissapears from the field when a user enters text.
  • Use 1 of 3 ways to label a form field:
    • Visible label with Label (preferred)
    • Visible label that's associated to the textarea with aria-labelledby
    • Label directly using aria-label
  • Provide clear identification of required fields in the label or at the start of a form. If you use the required field indicator, include the form key at the start of the form.
    • Use the required prop to programatically indicate they are required to browsers.
  • Use Help Text and an error icon to show inline error text on any field that errors to make it visually clear that the field changed.
  • If the textarea has associated help text or error text, include the aria-describedby prop on the textarea. This should match the id of the help or error text.

The Textarea should include the base Textarea, along with supporting elements to compose a textarea field that gives the user the context they need to successfully fill it out:

  • Label — Every form field should have a label. The label should indicate what should be entered into field.
  • Required field indicator — If most of the fields on a form are optional, indicate the few that are required with text or a required indicator.
  • Help Text — Text that's placed below the field to help users prevent an error and describe what makes the form field successful
(information)

Accessibility insight

Make sure to connect the Label to the TextArea. This is done with the htmlFor prop on the label, and the id prop on the textarea. Those two need to match.

If the textarea has any associated help text, the textarea should also use the aria-describedby prop that equals the id of the help text. This ensures screen readers know the help text ties directly to the textarea.

Component preview theme
<>
<Label htmlFor="message" required>Message (at least 120 characters)</Label>
<TextArea onChange={()=>{}} aria-describedby="message_help_text" id="message" name="message" required />
<HelpText id="message_help_text">Enter at least 120 characters</HelpText>
</>

Textarea with add-ons (prefix/suffix text or icons)

Textarea with add-ons (prefix/suffix text or icons) page anchor
  • Prefix/suffix text — Text that can be used as a prefix and/or suffix to the value that is entered. Use prefix/suffix to help users format text.
  • Icon — Icons can be placed in the same area as the prefix and suffix text. Icons should trigger an action (e.g., clearing a field).
Component preview theme
<>
<Label htmlFor="short_bio" required>Short biography</Label>
<TextArea onChange={()=>{}} id="short_bio" name="short_bio" insertBefore={<Text color="colorTextWeak" as="span" fontWeight="fontWeightSemibold">Bio</Text>} required />
</>
Component preview theme
<>
<Label htmlFor="body" required>Body copy</Label>
<TextArea
onChange={()=>{}}
aria-describedby="body_help_text"
id="body"
name="body"
placeholder="Ahoy, World"
insertAfter={
<Button variant="link">
<InformationIcon decorative={false} size="sizeIcon20" title="Get more info" />
</Button>
}
/>
<HelpText id="body_help_text">Enter text for the copy area</HelpText>
</>

By default, the textarea is not resizable by the user. To change this, add the prop resize='vertical'.

You may also provide a maxRows prop to limit how much the textArea grows. By default this value is 10.

Component preview theme
<>
<Label htmlFor="message" required>Message (at least 120 characters)</Label>
<TextArea onChange={()=>{}} aria-describedby="message_help_text" id="message" name="message" resize="vertical" maxRows={5} required />
<HelpText id="message_help_text">Enter at least 120 characters</HelpText>
</>

Textarea with inline error

Textarea with inline error page anchor

Change a form field to its error state and use Help Text to add an inline error if the value entered doesn't pass validation requirements.

The error Help Text is placed below the field to inform a user of any errors in their value. The error text should replace and repeat the help text. Review the error state pattern for guidance on writing error messages.

Component preview theme
<>
<Label htmlFor="text_error">Description</Label>
<TextArea onChange={()=>{}} aria-describedby="text_error_help_text" id="text_error" name="text_error" hasError />
<HelpText id="text_error_help_text" variant="error">Enter a description.</HelpText>
</>

Use a disabled form field to show users that they can't interact with the field.

Component preview theme
<>
<Label htmlFor="text_disabled" disabled>Description (disabled)</Label>
<TextArea onChange={()=>{}} id="text_disabled" name="text_disabled" placeholder="Paste is a design system used to build accessible, consistent, and high quality customer experiences at Twilio. Paste is open source and contributions are welcome." disabled />
</>

Use a read-only form field when a field's value can't be changed, but users should be able to read or apply focus on the field. For example, use a read-only form field if a user needs to copy the value.

Component preview theme
<>
<Label htmlFor="text_readonly">Description (read-only)</Label>
<TextArea onChange={()=>{}} id="text_readonly" name="text_readonly" readOnly value="Paste is a design system used to build accessible, consistent, and high quality customer experiences at Twilio. Paste is open source and contributions are welcome." />
</>

A textarea field must have at least a label and a textarea.

Component preview theme
<>
<Label htmlFor="details">Details</Label>
<TextArea onChange={()=>{}} id="details" name="details" />
</>

Stack form fields vertically with $space-80 spacing between each field.

Component preview theme
<>
<Box marginBottom="space80">
<Label htmlFor="header">Header</Label>
<TextArea onChange={()=>{}} id="header" name="header" placeholder="Ahoy, World!" />
</Box>
<Box>
<Label htmlFor="footer">Footer</Label>
<TextArea onChange={()=>{}} id="footer" name="footer" placeholder="Bon voyage" />
</Box>
</>

Avoid placing multiple form fields on the same horizontal row to help make it easier to scan a page vertically. Use the Grid component if you need to place form fields horizontally.

Labels should clearly describe the value being requested. They should be concise and descriptive, not instructional. To do this:

  • Use Help Text to provide instruction if needed. For example, don't use "Enter the registration code on the back of your SIM card below" as label text. Instead, use "SIM registration code" as a label and "Find the registration code on the back of your SIM card" as help text.
  • Avoid articles (like "a" and "the") and punctuation. For example, use "SIM registration code" rather than "The SIM registration code".

To support internationalization, avoid starting a sentence with the label and using the field to finish it since sentence structures vary across languages. For example, use "Call log expiration date" or "How long should logs be stored?". Don't use "Remove logs after:".

Give users enough information in help text to prevent textarea and formatting errors. Keep it concise and scoped to information that will help with validation. For example, use help text if a password field has specific requirements that a user should know prior to filling it out.

Required field indicator

Required field indicator page anchor

Ask for information only when needed. Consider removing the field otherwise.

Use text or required indicators to show users which fields they must fill out.

Validate form fields on form submission.

Validating a form field when the user leaves the current field (on blur) can be helpful to check for syntax errors. However, this can be frustrating to users who tab through controls to navigate a page, and to screen reader users, who might not be able to detect that an error occurred on blur.

Don't prevent form submission by disabling the submit button. A disabled button cannot be detected by assistive technologies. Use error messages to explain what information is missing or incorrect.

Use Help Text to show an inline error that to explains how to fix the error. For additional guidance on how to compose error messages, refer to the error state pattern.

Optional compositional elements

Optional compositional elements page anchor
  • Prefix/suffix — Use a prefix or suffix to help users format their textarea and to provide more context about the value a user is entering. For example, you could prefix or suffix a field with a currency symbol, or use suffix to append a character counter. Make sure to consider internationalization when using prefixes or suffixes since formatting may differ across languages. For example, currency symbols are placed on the left in American English, while they're placed on the right in French. Don't use prefix/suffix text as a replacement for a label.
  • Icon — Use an icon if you need to give the user additional controls for the field. For example, use an icon to clear a field on click, removing the need for users to manually delete their entered value. Place icon buttons that trigger an action on the right side of the field. If you need 2 actions on a field (e.g., popover trigger and clear field), place the icon button that affects the field value on the right, and the other icon on the left.

Use a textarea when users are expected to enter text that exceeds a single line, usually longer than a sentence.

Do

Use a textarea to encourage longer text entry.

Don't

Don't use a textarea when text entry is expected to be short since it could confuse users. Use an input instead.

Limit to 120 characters
Do

If you limit the length of text entry, show a character counter and explain to users in help text why their entry is restricted.

Don't

Don't have a character limit if you can't explain to the user why their text entry is restricted.

Type in: "Paste is open source and contributions are welcome."
Do

Use help text to help users prevent errors and fill out a form field correctly.

Don't

Don't use placeholder text for validation instructions.

This is a required field. Enter some text.
Do

Keep help text and error text concise and simple. If you need to use more than 2 sentences to explain a field, link out to supporting docs or trigger a popover instead.

This field is needed to submit your document. If you don't enter any text, your submission will fail. Please enter some text into the field. This will make the field valid.
Don't

Don't use more than 2 sentences in help text or error text.

Do

Include a visible label on every form field.

Footer text
Don't

Don't use prefix/suffix text as a replacement for a label.

Do

Use a disabled form field to show users that they can't interact with the field, but that it could potentially be enabled through another UI element.

Don't

Don't use a disabled form field to show information that can't be edited. Instead, use a read-only form field or consider another way of showing static information.