Text Input

Email fields appear and function identically to standard input fields. The only difference is that the ‘input type’ property should be set to ‘email’ to display the appropriate virtual keyboard on supported devices (for example phones and tablets).

Errors appear when the input entry, or lack thereof, fails validation. In that case, a red error message appears that should describe the error and how to fix it as clearly and succinctly as possible.

The width of the text input helps guide the user’s text entry. It’s generally a good practice to size the field to the entry parameters. For example, a ZIP code field will be shorter than a street address field.

Text input components can contain masking, which depending upon development or business requirements, will help prevent formatting issues for dates, addresses, currency, phone numbers, and around localization. While masking can help correct these errors, preventing them entirely with clear helper text is always preferred.

A text input with a button requires a text-only or icon-right variant button to avoid confusion with the warning icon in the input field. Display the button and input field flush together, in the same horizontal space.

Labels should describe the purpose of the input and every input field should have a label. Label text should be left-aligned (or right-aligned for right-to-left languages) with the input. Write label text in sentence case and be as succinct as possible.

Helper text appears below the text field. It is instructional text that helps the user fill out the relevant field. Keep the content concise, with as few words as possible to guide users and help them prevent errors.

For phone number text inputs there are two general functions that impact design: internationalization and localization.


For localized forms with phone numbers, the recommended best practice is to use one field for the entire phone number, along with geolocation and input masking. As the user fills in the field, parentheses and dashes are applied automatically. In this case, the helper text might say: Enter a 10-digit phone number.


Depending on localization or internationalization design requirements, product teams can choose whether to implement a separate select component for country code selection. If opting to support a separate country code selector, a select menu is required. The country selector will default to the page’s localization and will validate against the country’s formatting guidelines.

Placeholder text is optional, but be sure to use it in combination with helper text. Using placeholder text on its own introduces accessibility problems since it’s not read by screen readers. Because it disappears when the user begins entering text, it can be difficult for people to remember the information provided by the placeholder text. Be sure that helper text and placeholder text are not identical. When using placeholder text in conjunction with helper text, placeholder text should supplement the information in the helper text rather than replace it. Placeholder text typically provides users with an example entry for a given field.

To reduce confusion and visual noise, limit optional field entries and display only those which are required. Instruct users with introductory form text that states: “All fields are required unless marked optional.” Optional fields should be written as: Label (optional).

Make sure all labels are clear, concise, and unique
All users should know from the label exactly what information is needed to successfully complete the field.
WCAG 2.1: 1.3.1 Info and Relationships


Avoid using placeholder text for conveying important information
Use helper text to relate this information instead, as instructions must be visible at all times. Placeholder text disappears as the user starts typing, requiring them to delete their entered text if they need to refer to that information again.
WCAG 2.1: 1.3.1 Info and Relationships, 3.3.2 Labels or Instructions


Make sure all helper text and error messages provide meaningful assistance in helping users avoid or fix errors
Don’t provide unclear helper text, such as “Enter a valid email address.” Instead, make it clear how a valid email address should be formatted.
WCAG 2.1: 3.3.2 Labels or Instructions, 3.3.3 Error Suggestion


Warn users in advance about fields that have masking and autoformatting requirements
If a field requires a specific kind of formatting, such as whole numbers, or a limited number of characters, communicate that in advance using helper text.

North American phone number format
For the US, Canada, and other NANP (North American Numbering Plan) countries, use hyphens (not parentheses, periods, or spaces) in phone numbers.
Example: 512-459-2222


International phone number format
Include the country and area codes for all non-NANP countries. Use spaces, rather than hyphens, to separate the groups of numbers. Country codes are preceded by a plus sign with no space following it.
Example: +19 777 555 5555