Textarea

---

Anatomy

1. Label: (Optional) Descriptive text that helps users understand what information to enter in to the field
2. Container: The bounding box that contains all of the color, text, icon, of the field
3. Input Text: The text that the user enters into the field
4. Resize Control: Control that allows the user to resize the text area

---

Usage Guidelines

When to use this component

• Use a Textarea when you need a user to input multiple lines of text. This is ideal for comments, messages, descriptions, or feedback where the length of the content is variable and can't be contained in a single line.
• Use a Textarea when you need to provide a large, flexible input area that gives the user a clear sense of how much they can write.
• Use a Textarea when a user needs to write a long-form response, like in a support ticket or a review.

When not to use this component

• Do not use a Textarea for single-line input. A standard text Input is more appropriate and semantically correct for fields like a name, email address, or phone number.
• Do not use a Textarea when you need to enforce a strict, single-line format, such as a password or a URL. A dedicated Input type is better suited for these specific data types.
• Do not use a Textarea when a user needs to select from a predefined list of options. A Dropdown, Radio Buttons, or Checkboxes are the right components for this.

---

Best Practices

---

General Component Behaviors

Labels

Labels indicate what type of data the field needs. Having labels present gives us two major advantages:

• They are programmatically associated with the field, which means assistive technologies will read them when the user focuses on them.
• When the user click/tap on the label, the browser passes the focus to the field, which makes it easier for touch screens, and users with motor disabilities.

Important note:

Labels should always be present, unless for those cases where the context and elements that surround the Textarea make it clear what data is needed (e.g. a field in a chat). In those cases, make sure an aria-label is used.

Placeholders

Use the placeholders to help users understand the format needed. They can never be a substitute for the label or hint because:

• They disappear as soon as the user interacts with the field.
• They usually do not meet a strong contrast ratio (+3:1 in our case).
• Screen readers do not read placeholders as they do labels.

Hint & errors

Hints and error messages provide additional directions to support the label meaning in an accessible manner.

Resizing

If needed, a user can resize the text area by dragging the control to have access to more content space.

---

Responsive Behavior

Inputs are designed to be responsive, shrinking to fit the available browser space. As the container shrinks, the input's horizontal padding and margins decrease to preserve space. If the content exceeds the input's width, it will be truncated with an ellipsis to maintain a clean layout.

When the input hits a mobile breakpoint the container padding becomes larger to accommodate mobile touch points and the text size increases.

---

States

---

Content Guidelines

1. Match the user's mental model. If the user is writing a review, use language that reflects that, such as "Write your review here."
2. Use sentence case. This improves readability and scannability, especially for longer labels or hint texts.
3. Keep a consistent tone. The tone of the content around the textarea should align with the overall voice and tone of the product.
   

For further information, see the Content Styleguide.

---

Known Gaps

• Accessibility guidelines