GitHub
Text input
Text input allows a user to enter or edit small, specific pieces of text.
Usage
Do
- Use to obtain small pieces of text or number input.
- Use a placeholder to hint at the text input’s purpose.
- Match the size of the input to the amount of intended text.
- Mask input for secure text entry.
Don't
Avoid using when the input could contain large amounts of text. Use a text area instead.
Anatomy
- Text: the text entered into the input field.
- Background: the colour of the component backdrop.
- Clear Button: a button to clear the input field.
- Prefix: the section on the left with an icon or unit value.
- Suffix: the section on the right with icon or unit value.
- Border: a linear frame around the text field.
- Placeholder: a text example in the field before it’s replaced by text input.
Live playground
Types
A default text input has an empty placeholder for users to input data.
Variants
Text input can be styled in the following ways.
- With prefix includes an additional symbol that relates to the context of the input.
- With suffix includes an additional value or unit of measurement.
- With icon includes an icon.
States
- Default has an empty placeholder for users to input data.
- Focused communicates when a user has highlighted an element, using an input method such as user tap, cursor, mouse or keyboard.
- Hover provides feedback on mouseover, indicating the item is interactive.
- Invalid indicates an error.
- Disabled indicates the element is not interactive and cannot be selected.
Format
Size
Text input is available in small, medium and large sizes.
Alignment
Icons, prefixes and suffixes are aligned to the left or right of the input, and centre-aligned within it.
Content
Labels
Clear, concise labels guide the user on which data to input.
Placeholder text
Placeholder text in the field assists the user with examples of what data is needed, and disappears once the user begins entering it.
Error messages
To enable the user to correct input errors, a precise and constructive error message can be revealed. It is recommended that validation is real-time.
Accessibility
Shell DS components are programmatically determinable with appropriate semantic markup and are designed to meet colour contrast requirements. If you’re not using Shell DS code, you will need to cover the accessibility considerations for each component in this pattern.
- All non-text content must have a text alternative that serves the equivalent purpose (e.g. alt text for the icon).
- The name and role of the text input must be programmatically identifiable for assistive technology (AT), so that the AT users understand what it is and how to use it).
- Hints and errors should be read after the text input label (e.g. Enter your comments – 100 characters remaining).
- The state is programmatically identifiable for AT, and changes to the states must be available to AT.
- The label must be programmatically associated with the text input, explicitly whenever possible.
- The label must describe the topic or purpose of the text area so users know what input is expected.
- Placeholder text should not be relied upon as a label for text input, as it is temporary.
Every effort has been made to ensure that the Shell Design System follows accessibility best practice.
The Shell DS React framework incorporates keyboard operation to support the widest variety of assistive technologies and devices. For any future frameworks other than React, accessibility will need to be reviewed.
Help us to help you by contacting the Accessibility team for support and information regarding any questions relating to accessibility.
Related
Is this page useful for you?
Your feedback helps to improve our documentation.