Textarea

Problem Context

• The answer is freeform and may include sentences, paragraphs, pasted text, or line breaks.
• The product may need to warn users about sensitive information, maximum length, minimum detail, or disallowed characters.
• Users may spend significant time composing the answer and expect editing, undo, paste, spellcheck, mobile keyboard, and back navigation to preserve their work.

Selection Rules

• Choose textarea when the expected response is more than a short single-line answer.
• Use enough visible rows for users to review the likely answer without excessive scrolling.
• Prefer text input for short values that should not include line breaks.
• Add a character count only when there is a real limit or users need help staying within a policy constraint.
• Use rich text editing only when formatting, links, headings, lists, or structured content are part of the task.
• Explain sensitive-data restrictions in hint text before users start writing.
• Validate required, too-short, too-long, and disallowed-character states after interaction or attempted submit.
• Preserve text exactly, including line breaks, unless the product previews and explains a transformation.

Required States

• Empty untouched state with visible label and optional hint.
• Focused writing state with caret, wrapping text, and visible focus indicator.
• Filled multi-line state preserving line breaks and pasted content.
• Remaining-count state when a real maximum length is configured.
• Required empty error state after attempted submit.
• Too-long or too-short error state with specific length guidance.
• Disabled state when the textarea cannot be edited.
• Recovered draft state after validation or navigation back.

Interaction Contract

• Typing, selection, line breaks, paste, undo, redo, and spellcheck follow native textarea behavior.
• The label remains visible while the user writes and reviews multiple lines.
• Hint, count, and error text are associated with the textarea when present.
• Submitting invalid long text keeps the user's draft in place and explains the exact fix.
• Character count updates as text changes and does not replace specific validation errors.
• Tab leaves the textarea in normal form order unless the product intentionally supports tab insertion and documents it.

Implementation Checklist

• Use a native textarea with id, name, rows, label, and descriptive associations before creating a custom editor.
• Set rows and CSS resizing behavior to suit expected answer length and page layout.
• Add hint text for examples, sensitive information, expected detail, or content restrictions.
• Add maxlength and remaining-count feedback only for real limits; include too-long recovery text on submit.
• Preserve textarea value across client validation, server validation, page reload, browser back, and draft restore paths.
• Configure spellcheck, autocapitalize, autocomplete, and disabled state based on the content being collected.
• Test keyboard editing, screen reader label and description announcement, paste, line breaks, mobile keyboard coverage, zoom, and long-text scrolling.

Common Generated-UI Mistakes

• Using a single-line input for paragraph answers.
• Using textarea for short codes, names, or titles that should stay one line.
• Clearing a long draft after validation fails.
• Showing a hard character limit only after submit.
• Silently truncating pasted paragraphs.
• Using a rich text editor for plain text comments.
• Making the textarea so short that users cannot review what they wrote.
• Leaving sensitive-data instructions until after the user has already written the answer.

Critique Questions

• Does this answer need multiple lines, paragraph review, or pasted long text?
• Can users see enough of their answer to review it before submitting?
• Are character limits real, visible, and recoverable?
• Are hint, count, and error text announced with the textarea?
• Will drafts survive validation failures, reloads, and navigation back?