Implement correctly
Build Textarea without breaking its behavior
# Implement Textarea in your agent ## Objective Implement Textarea for this verified behavior: A labeled control for entering or editing free-form text across multiple lines. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Textarea matches the need before writing code. ## Required behavior - Enter inserts a new line, and the control can grow or scroll without hiding its label. - A specific inline message identifies the invalid field and explains how to correct it. ## States to cover - Draft within limit - Draft over limit ## Accessibility - ARIA role: textarea - The primary control or named region for Textarea has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Visible focus surrounds the control and remains visible while the user scrolls within long text. - Not applicable: the draft remains until reset, submitted, or deliberately cleared. - Label, multiline role, helper, character limit, current invalid state, and error are exposed without announcing every keystroke count. - Tab focuses the textarea - Enter inserts a new line - Native editing and scrolling shortcuts remain available ## When not to use - The value should remain one short line - Users need rich-text formatting rather than plain text ## Acceptance criteria - Enter creates a line break - The visible label and guidance remain associated - Resize or auto-grow never hides content or actions - Length errors preserve the draft and explain recovery ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- Web platform
- Requires · Access to the repository, design system, and tests
Why it works
- The need is tied to canonical behavior before any technical choice.
- States, accessibility, and non-goals prevent a merely visual implementation.
- Acceptance criteria and the output format make verification observable.
Try next
Verify Textarea on a real journey
# Verify Textarea after implementation ## Objective Audit the Textarea implementation against its behavior, states, and accessibility requirements without changing it automatically. ## Checks - Replay the smallest representative journey. - Check keyboard behavior, focus, accessible name, and announcements. - Tie each gap to a specific acceptance criterion. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:79bea26585c056de0ebbc132fb46fbe7e9ac60283a9e3e15a8b69adb8b1abeec