Text Field

Status: Aetna CVS View in Android SDK Reference

An input element that accommodates both single and multiline text entry. Most commonly used within a form.


Text Fields can be used for prompting the user to enter text-based input values such as:

  • Text (e.g. first name: alpha)
  • Passwords (alphanumeric)
  • Phone Numbers (numeric)
  • Numbers Decimal (e.g. currency: prefix $ + numeric)
  • Numbers (e.g. Credit Card or SSN)

Certain types can be combined, e.g a SSN field can have show/hide functionality similar to a password field.



Number Decimal


Always use a label that clearly identifies the input content

Helper Text

Helper text conveys additional guidance about the input field, such as how it will be used.

Multi-line Text Field

Multi-line supports large font sizes and/or lengthy amounts of free-form text (alpha and numeric) that wraps and extends beyond one line. The Text Field will automatically increase in height (from top-to-bottom) to accommodate wrapping text.

Use a multi-line Text Field for potentially multi-line text, like ratings or messages to providers. Use a character counter only when appropriate.

Input Masking

Prefix and Suffix

Use affixes (prefix/suffix) when it’s supportive of input value
Never use an affix as a label or a placeholder



As soon as a user begins typing the first character, a clear button appears to allow users to clear any entered text.

Validation & Errors

Upon validation, if the Text Field does not have valid input, an error message will be presented. Error messages should not replace helper text.

Visual Style

Always maintain 16dp vertical spacing between Text Fields
Never use an affix as a label or a placeholder

Character Counter

Content Strategy


Text entry is implied in Text Field, so omit actions for short-entry labels. You might consider more actionable, branded labels when prompting long-form responses.

  • Aetna: Use Title case for labels
  • CVS: Use Sentence case for labels

Placeholder, Helper Text & Masking

Placeholder text is not built into the Text Field component. Instead, use helper text above the field to give guidance as needed.

Use masking as appropriate to communicate expectations and formatting, reducing the chance for errors.

Requirement & Errors

Mark optional fields as such. Otherwise fields are assumed required.

  • Form views with multiple fields should display “All fields are required unless marked optional”

View Aetna’s error guidelines.



  • Edit state: Label and Helper Text must be programmatically connected to Text Field
  • Error state: Text Field should only show error validation messages after a user has interacted with a particular field
    • Only notify if character limit is exceeded, don’t use a total character remaining countdown
  • Completed: Valid data entered and tap “done” or “next” within keyboard

Focus Expectations

  • Swipe to move focus among Text Fields
  • Tap to enter an input, edit content, and remove content
  • Error state should be announced upon focus
  • Tap “next” in keyboard to move focus to next Text Field, * if no additional Text Field, tap “done” to exit keyboard
  • If applicable, input masks receive focus (i.e. password toggle button, affixes)

Screen Reader Expectations

Reading Order

  • “{Label Name}, {Helper Text}, edit box”
  • Disabled: “{Label Name}, {Helper Text}, edit box, disabled”

Error Handling

  • Once an error is triggered within a Text Field, user should immediately hear the error message before moving focus to another Text Field
  • If an error is already present on a Text Field, the error message should announce when focus is moved to the Text Field with the error
  • Reading order: “{Label Name}, {Helper Text}, {Error Message}, edit box”
↑ Back to top