- Allowing users to input long portions of free-form text while ensuring all text entered remains visible.
- Allowing users to type free-form options that get converted into Tags within the TextArea.
- For inputs that expect a certain format, like a date or email. Use a DatePicker or TextField instead.
Use TextArea as an affordance to input longer-form text content — typically anything longer than a brief sentence.
Use TextArea when the text input is a single, non-sentence response — even in cases with long content. Use TextField instead.
label to clearly denote what information the user should input. Use
placeholder sparingly as they can erode usability of form fields.
placeholder as a replacement for
label, as this creates accessibility and usability issues.
helperText to provide additional context that will aid the user in most effectively inputing information.
placeholder to provide any information necessary to filling out the form field. Placeholder text disappears after the user begins entering data and should not contain crucial information.
Set the height of TextArea using
row to ensure that the typical amount of text entered will be visible without needing to scroll.
row prop to less than 2. Use TextField when expecting only a single line of text.
Be sure to provide instructions to help users understand how to complete the form and use individual form controls.
Ensure the labels are precise and concise. Labels should only describe the text field they are associated with, and they must be visible. If you cannot use the
label prop, ensure the alternative label's
htmlFor attribute matches the TextArea's
id. Labels are properly associated when clicking the label focuses the TextArea.
When providing a validation message, make sure the instructions are clear and help users complete the field. For example, "This field is required to submit". In addition, use the helper text to provide instructions to help users understand how to complete the text field or to indicate any needed input, allowed formats, timing limitations, or other pertinent information.
These practices give users of assistive technologies more information about the form, helping them to fill it out.
TextArea has conventional keyboard support.
- Users relying on the keyboard expect to move focus to each TextArea by using the tab key or shift+tab when moving backwards.
disabledwill prevent TextArea from receiving keyboard focus or input.
TextArea intentionally lacks support for autofocus. Generally speaking, autofocus interrupts normal page flow for screen readers making it an anti-pattern for accessibility.
TextArea is commonly used as an input in forms alongside submit buttons. In these cases, users expect that pressing Enter or Return with the input focused will submit the form.
Out of the box, TextArea doesn't expose an
onSubmit handler or individual key event handlers due to the complexities of handling these properly. Instead, developers are encouraged to wrap TextField in a
<form> with an
Be sure to localize
TextArea will expand to fill the width of the parent container by default.
Whenever you want to provide more information about a form field, you should use
In some cases, the label for a TextArea is represented in a different way visually, as demonstrated below. In these instances, you can set
labelDisplay="hidden" to ensure TextArea is properly labeled for screen readers while using a different element to represent the label visually.
TextArea can be in read-only mode in order to present information to the user without allowing them to edit the content. Typically this variation is used to show content or information that the user does not have permission or access to edit.
TextArea can be disabled to indicate the user is unable to interact with it, either by mouse or keyboard. Disabled fields do not need to pass contrast requirements, so do not use a
disabled TextArea to present information to the user (use
TextArea can display an error message. Simply pass in an
errorMessage when there is an error present and TextArea will handle the rest.
errorMessage to provide feedback on character count errors. See the maximum length variant for more details.
TextArea supports the native maxlength input attribute.
maxLength sets the maximum number of characters allowed to be entered by the user in TextArea.
maxLength must be an integer value 0 or higher.
The user cannot exceed the maximum number of characters interacting with the component. Whenever possible, avoid setting initial values from the parent component's state that already exceed the
maxLength is passed to TextArea, the component displays a character counter as well as a warning or problem Status when the user reaches or the prepopulated controlled value exceeds the maximum length of characters.
The first example shows an empty TextArea with
maxLength set to 200 characters. The second example shows the warning and problem Status.
With a ref
TextArea with an anchor ref to a Popover component
You can include Tag elements in the input using the
Note that the
TextArea component does not internally manage tags. That should be handled in the application state through the component's event callbacks. We recommend creating new tags on enter key presses, and removing them on backspaces when the cursor is in the beginning of the field. We also recommend filtering out empty tags.
This example showcases the recommended behavior.
Component quality checklist
Component is available in Figma across all platforms.
Component is available in code for web and mobile web.
Component is not currently available in code for iOS.
Component is slotted to be built for Android.
TextField is ideal for short-form, single answer text input.
Tag can be used in conjunction with TextArea to display separate elements of content.
ComboBox + Tag is the recommended alternative to TextArea + Tag when selecting from a finite list list of items.