Explore behaviors before defining the interface.
Quick guide for designers
Always consider the context of the application, even when the guidance follows a standard pattern. Interaction design documents intent. Behavior must be verified in the implementation.
When to use
Use for single-line text. For multiline answers, choose a field suited to that purpose.
What to draw
Show a persistent visible label and empty, filled, and error states. Include focus, disabled, and read-only states where applicable. Distinguish states without relying on color alone.
How it behaves
Clicking or tapping the field or its associated label allows editing. Keyboard navigation follows interface order and is not trapped in the field. On error, preserve entered text and explain how to correct it.
What to document in Figma
Record the label, instructions, required status, limits, and error messages. Define Enter behavior in the form and navigation order. Document what information screen readers should announce.
How to review
Does the label remain visible after entry? Does the error explain the correction? Can people still see and edit the field with zoom and the virtual keyboard? Label association, announcements, and keyboard editing need implementation checks.
Full guidance
Interaction Design
Questions to ask when designing Input "text" components.
Assess each guideline according to the component's context of use.
Designing for "no interaction"
- Does the label remain visible and explain the field's purpose?
- Are instructions, required status, and limits available before entry?
- Are empty, filled, invalid, disabled, and read-only states distinguishable without relying solely on color?
Designing for mouse use
- Does clicking the field or its associated label focus it for typing?
- Do focus and associated controls provide perceptible visual feedback?
Designing for gesture use
- Does the touch area allow selecting the field and its controls without accidental activation?
- Do the virtual keyboard and zoom allow the field to remain visible and editable?
Designing for keyboard use
TabandShift + Tabmove through controls in interface order?- Can you edit and select text using native commands without trapping focus?
Designing for screen reader use
- Are name, type, required status, instructions, and errors presented understandably?
- Is the label associated with the field and still available after filling it in?
Interaction methods
The field accepts single-line text; line breaks require another component, such as a textarea.
Mouse interaction
- Clicking the field or its associated label puts focus in the field.
- Selecting, editing, copying, and pasting follow the field's native behavior.
Keyboard interaction
Tabmoves focus to the field;Shift + Tabreturns to the previous control.- Typing inserts text;
arrow keys,Home,Endand selection and editing commands follow the platform. Enterfollows the form's defined submission action; the field does not create a new line.
Gesture interaction
- Tapping the field or label allows editing with the virtual keyboard.
- Text selection and editing follow the platform's available gestures.
Keyboard (or gesture) interaction + screen reader
- When navigating to the field, the reader presents its label and type, along with associated states and instructions.
- Errors are associated with the field and explain how to correct the information; the entered value is preserved.
Gherkin
BDD (Behavior-Driven Development) methodology focusing on three pillars: User Stories, Acceptance Criteria, and Gherkin Syntax (Given, When, Then).
Scenario: Given that I am on a page containing Input "text"
Keyboard navigation
- WHEN I use the
Tabkey to move focus to the field - The focus I SEE is strongly indicated visually
- THEN, when I type, select, or edit content using native commands
- I SEE the field value updated
- AND, when I use
TaborShift + Tab, I SEE focus follow page order without getting trapped in the field
Desktop screen reader
-
WHEN I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and use the
Tabkey to move focus to the field, the following happens:- I HEAR the field's label and purpose.
- I HEAR that the component is a text field.
- I HEAR the required status, instructions, and associated errors, when present.
- THEN, when I type or edit content using native commands
- I HEAR or perceive that I can edit the field and that its value was updated.
Mobile screen reader
-
WHEN I use a screen reader on a phone (TalkBack, VoiceOver) and swipe to focus the field, the following happens:
- I HEAR the field's label and purpose.
- I HEAR that the component is a text field.
- I HEAR the required status, instructions, and associated errors, when present.
- THEN, when I double-tap or use the appropriate gesture to activate the field and edit its content
- I HEAR or perceive that I can edit the field and that its value was updated.
Input validation
- WHEN an entry is rejected by a stated validation rule
- I SEE a message associated with the field explaining how to correct the information
- AND, when I navigate to the field with a screen reader, I HEAR the error indication and associated guidance
- THEN, when I edit again, I SEE the value preserved for correction
Considerations
- Use a persistent label associated with the input. A placeholder is a supplementary hint and does not replace the label.
- Associate instructions and errors with the field, for example using aria-describedby, and set aria-invalid when there is an error.
- Indicate required status and use required when needed. Do not communicate errors solely through color.
- Keep focus visible and ensure adequate contrast and interaction area.
- Respect native selection, editing, copying, and pasting. Set length limits only when needed and state them before entry.
References
Field documentation
Design System
- GOV.UK — Text input open_in_new (external link, opens in a new tab) — Single-line text field, labels, instructions, and errors.
- Carbon — Text input open_in_new (external link, opens in a new tab) — Text field states and behaviors.
- USWDS — Text input open_in_new (external link, opens in a new tab) — General guidance on text entry.
- Bootstrap — Form controls open_in_new (external link, opens in a new tab) — Field and state implementation examples.