Data Entry
A text area lets a user input a longer amount of text than a standard text field. It can include all of the standard validation options supported by the text field component.
A text area should always have a label. In rare cases where context is sufficient and the UX Team have reviewed the design, the label could be undefined. A text area without a visible label should still include an aria-label in HTML (depending on the context, “aria-label” or “aria-labelledby”).
Labels can be placed either on top or on the side of the field. Top labels are the default recommendation because they work better with longer copy, localization, and responsive layouts. Side labels are most useful when vertical space is limited.
The value shows a user’s entered text.
The width of a text area can be customized appropriately for its context.
Text areas come in three different sizes: small, medium and large. The medium size is the default and most frequently used option. Use the other sizes sparingly; they should be used to create a hierarchy of importance within the page.
Text areas can be marked as optional, depending on the situation. Optional text areas are either denoted with text added to the end of the label — “(optional)” — or have no indication at all.
Text areas can display a character count indicator when the length of the text entry needs to be kept under a predefined value. Character count indicators can be used in conjunction with other indicators (e.g. “optional” indicators) when necessary.
A text area can be marked as having an error to show that a value needs to be entered in order to move forward or that a value that was entered is invalid. If an error exists, the error icon always overrides any other icon.
A text area in a disabled state shows that the input field exists, but is not available in that circumstance. This can be used to maintain layout continuity and communicate that a text area may become available later.
Text areas have a read-only option for when content in the disabled state still needs to be shown. This allows for content to be copied, but not interacted with or changed. A text area does not have a read-only option if there is nothing entered in it.
Text areas can either be a static size or can be resizable with a drag icon in the bottom right corner. Text areas are resizable by default. The drag icon should be hidden if the text area should not be resizable.
A text area can have help text below the field to give extra context or instruction about what a user should input in the field. The help text area has two options: a description and an error message. The description communicates a hint or helpful information, such as specific requirements for correctly filling out the field. The error message communicates an error for when the field requirements aren’t met, prompting a user to adjust what they had originally input.
Text areas are ideal for long sentences or paragraphs, and should comfortably accommodate larger amounts of text. They should have a minimum height of 3rem (when the height of the text area is a defined number). The minimum width is 7rem.
When typing into a text area and reaching the end of the field on a number-height text area, the cursor should remain as static in the bottom right corner (for left-to-right languages) while text above it overflows through the top of the field. When the field loses focus, text should overflow through the bottom of the text area, showing the beginning of the text.
When the help text is too long for the available horizontal space, it wraps to form another line.
Description and implementation notes
<p> code example </p>Includes all interactive states that are applicable (hover, down, focus, keyboard disabled).
Works properly across all color schemes (light, dark).
Text has a contrast ratio of at least 4.5:1 for small text and at least 3:1 for large text (WCAG 2.0 1.4.3).
Visual information required to identify components and states (except inactive components) has a contrast ratio of at least 3:1 (WCAG 2.1 1.4.11).
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc).
Includes guidelines for keyboard focus, layout(wrapping, truncation, overflow) animation, interactions etc.
Includes a list of dos and don'ts that highlight best practices and common mistakes.
Includes content standards or usage guidelines for how to write or format in-product content for the component.
Works properly across various locales and includes guidelines for bi-directionality (RTL).
Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.
All design attributes (color, typography, layout, animation, etc.) are available as design tokens.
Includes a downloadable Figma file that shows multiple options, states, color themes, and platform scales.