Text input in Platforms Code are interactive elements where users can enter or edit text, numbers, or other data. They provide a means for users to input information, such as usernames, passwords, or search queries, and are commonly found in forms or search bars. Input fields typically feature visual cues like placeholder text or labels to guide users and enhance usability.
Appearance
The Platforms Code Design System offers a wide range of input field variations tailored to diverse design needs and user interactions, accommodating various elements inside the container. This variety of inputs caters to a wide range of user interactions, ensuring flexibility and adaptability.
Types
Inputs are available in four types:
- Standard input: A standard input is a fundamental user interface element that allow user to enter any information using their keyboard.
- Input with Icon: A standard input field featuring an icon to visually represent its purpose.
- Input with prefix and suffix: An input field with two visually separated extended containers, often interactive, used to provide contextual information. For example, adding the country code before the phone number or the currency symbol after the amount.
- Read only Input: A Read-Only Input is a text field within a UI that displays information but doesn't allow user modification.
Filled styles
- Filled - Default: The default style of the filled input with a standard background and stroke.
- Filled - Lighter: A lighter style of the filled input with no stroke and a light background.
- Filled - Darker: A darker style of the filled input with no stroke and a darker background.
Helper Texts
- Helper Texts: This is a standard input field accompanied by supporting information. It is designed to guide users to enter accurate data, providing additional details about the field.
- Error Helper text: Similar to the standard helper text, this input field is highlighted in red to indicate unsuccessful data entry. It guides users to correct their input, offering extra information about the error encountered.
Behaviors (States)
Inputs in the Platforms Code exhibit various behaviors depending on user interaction. These behaviors include:
- Default: The initial state of an input field when not being interacted with, appearing as a standard, editable field.
- Hovered: Triggered when the user hovers over the input field without clicking, providing visual feedback.
- Pressed: This state is triggered when the user clicks or taps the input field, providing feedback that the field has been successfully activated.
- Focused: Occurs when an input field receives keyboard focus, typically through the "Tab" key, essential for accessibility to navigate through the interface using the keyboard.
- Disabled: A state indicating that the input field is not editable or interactive, often used in user interfaces to communicate that the input field cannot be modified under the current circumstances.
Anatomy
- Container: The editable area that holds all the elements
- Input label: Displays the title of the input.
- Placeholder: A hint or example text shown inside the input field when it is empty.
- Icon: Provides visual representation of the input purpose/name.
- Feedback icon: Provides visual representation of the entry validity.
- Helper Text: Provides user with extra information to help deli.
- Prefix: Information added before the main input field to provide contextual information.
- Suffix: Information added after the main input field to provide contextual information.
Accessibility
Ensuring that these input fields are accessible is crucial because they often form the backbone of user interactions on websites and applications. Here’s a detailed accessibility guide for creating accessible input components.
- Use the correct HTML elements and types for the input to ensure that the browser and assistive technologies can correctly interpret the element's purpose.
- Ensure that all input fields can be accessed and used via the keyboard alone.
- Use specific type attributes for <input> elements when appropriate, such as email, tel, number, etc., to invoke the correct keyboard and provide built-in validation in some browsers.
<input type="email" id="email">.
- Use label> elements to provide a clear, descriptive label for each input. For screen readers, associate the label with the input using the for attribute that matches the input’s id If a visible label is not desirable (eg., for design reasons),use aria-label or aria-labelled by to provide an accessible name.
<label for="email">Email:</label>
<input type="email" id="email" name="email">.
- Use aria-describedby to link any additional descriptive text or error messages to the input, helping users understand constraints or corrections.
<input type="text" id="username" aria-describedby="usernameHelp">
<small id="usernameHelp">Your username must be 8-20 characters long.</small>
- Ensure that users can navigate to and from the input field using standard keyboard controls Tab and Shift + Tab
- Clearly indicate fields that have errors after validation and provide helpful error messages. Use aria-invalid="true" on inputs with errors and link to a descriptive error message using aria-describedby
<input type="text" id="username" aria-invalid="true" aria-describedby="errorUsername">
<span id="errorUsername">Error: Username is already taken.</span>
- Provide clear visual indicators for focus states, such as borders or shadows, to help users determine which element is active.
- Ensure high contrast between text and background colors, and use legible font sizes.
- Ensure inputs are usable on all devices, with touch targets that are adequately sized for mobile users.