Text input

Label

• Avoid using generic single-word labels, like Name or ID for field labels.
• The ambiguous nature of these labels can cause users to be confused about their meaning.
• Also, Name or ID fields from other sources might appear on the same screen, causing confusion.
• Instead, always add a modifier to generic single-word labels, like Name or ID. For example:
• Employee name
• Project ID
• Expense type

Hint text

Use hint text only if the label does not provide enough context to help users interact with the input.

• Write hint text in full sentences with ending punctuation. This makes screen readers pause before reading out any error or warning message after the hint text.
• Do not use hint text that repeats the message in the label.

Placeholder text

You can use placeholder text if it does not provide critical information for users but instead provides a small amount of additional context.

• Make sure to provide enough context in the label and hint text so that users can easily interact with the input without the aid of the placeholder text.

Requirements

Users should be able to:

• Identify the input as a way to enter single line text.
• Enter, edit, and review their input using assistive technology.
• Receive and understand supporting hint text and error messages.

Interactions

Keyboard interactions

• Tab. Moves focus from the previous interactive field to the text input.
• When focus is on the input, typing will enter information into the field.
• Pressing 'tab’ when on the input moves focus to the next interactive field.
• Enter. Submits the form that the input is part of.

Design considerations

• The input should have a clear, visible label so that users can identify the purpose of the field
• Read-only and disabled text inputs should be avoided. Consider using static text instead.
• Make sure the input border has a 3:1 minimum contrast ratio with the background it's placed against.
• If certain formats are required by the user, make sure hint text clearly states the expected format.
• Use a form key and asterisks to indicate required fields.
• Users can use text inputs to enter information as part of a form. Pressing ‘enter’ when on form inputs will submit the form. This behaviour should not be disabled or changed, as it is against user expectation.

Development considerations

• If a field is required, display an asterisk beside the input label, and use therequired attribute on the field so that screen reader users can easily tell which fields are required.
• If hint text is used, it should be associated with the textarea using aria-describedby pointing at the unique id of the hint text.
• The input should be marked up as input type=”text” to allow users to enter any characters they need to.
• Text inputs should have clear error and warning states, associated with the text input using aria-describedby.
• Text inputs should be validated on form submission, not onblur, as this may be confusing and noisy for screen reader users.