Component Input

Anatomy

1. Label: Describes the expected input.
2. Text input: Where the user inputs data.
3. Helper text: Provides additional context if needed.
4. Input container: Displays the input field.

Labels

• Each field needs a label, which should be clear, concise, and obvious to users what the field is asking for.
• As with placeholder text, use sentence-case capitalization and consistent grammar and spelling in each label.
• Ensure that labels are visible.

<som-input id='usage-name' label='Full name' aria-label='Enter your full name' required></som-input>

Placeholder text

Placeholder text can give users an idea of what to put into an input. It’s optional, so don’t use it as a space to put important information or use it as a replacement for a label.

• Once the user begins entering their data into the input, placeholder text is removed.
• Some screen readers don’t read placeholder text aloud, which is why it shouldn’t be used for important information.
• Placeholder text should be short and informative. Use sentence-style capitalization and an active voice.
• Don’t use placeholder text as help text because it disappears on focus, while helper text remains visible.

Helper and error text

• Use helper text to clarify requirements for filling out an input, such as formatting rules.
• Use error text to explain mistakes made by users. Error text should be specific enough to correct errors.
• Use sentence case, write full sentences, and use punctuation.
• Helper text will appear underneath a field, except when an error message replaces it.

Required and optional fields

Not every input needs to be filled out. There are ways to establish when an input is optional.

• When possible, don’t ask for unnecessary information. This prevents users from getting overwhelmed.
• If most of the form’s fields are required, mark only the optional fields.
• If most of the form’s fields are optional, mark only the required fields.

By default, fields not marked as required will show “(optional)” indicators. It's possible to manually override this behavior to display indicators for required fields instead. Visit the code section to learn more.

Tooltips

Add a tooltip by setting the tooltip attribute to the desired text. Use tooltips sparingly, and keep text brief and supplementary. Do not include interactive elements. The tooltip appears on hover or keyboard focus.

<som-input 
  label="Username" 
  tooltip="Your username is your email address."
  required 
></som-input>

Behavior

States

• Default: The standard state of an input.
• Hover: When a user’s cursor moves over an input without clicking it.
• Focus: When a user highlights an input with a keyboard or the Tab key.
• Disabled: An unavailable action. Ensure that users aren’t confused as to why a text field is disabled.
• Error: When a field fails validation, an error message can display instructions on how to fix it.
  • Error messages are displayed below the input area, replacing helper text until fixed.
  • Real-time validation helps streamline the process and keep data clean when the user fills out forms. Otherwise, validate the text input data when the user submits the associated form.
• Read-only: Allows for content to be shown in a text area so that users can copy it, but not edit it.

Text overflow

If a user’s entry is too long for the input, text will flow off the right edge and be hidden by the boundary of the input. Add a character limit to prevent this.

Modifiers

Input type

Input types allow developers to specify the use or formatting requirements for an input. An input’s default type is text. To learn more about using input types, visit MDN Web Docs.

Input types include:

1. Text: A single-line text field.
2. Number: Accepts only numbers such as currency, measurements, and dates.
3. URL: Accepts only hyperlink URLs.
4. Tel: Accepts only properly formatted phone numbers
5. Email-only: Takes properly formatted email addresses.
6. Password: A field for a password or other sensitive information to be entered. Because users are entering private data, the data entered into these inputs are hidden.
7. Search: An input used as a search field.

Field elements

Text prefixes show information that goes before text, such as currency symbols or buttons. Improve a form’s cohesiveness by using formatting requirements.

Leading icons give users context about what input they’re expected to provide. For example, if it’s an email input, the leading icon might be an image of a letter.

Inputs can also have buttons that perform actions, such as clearing a field, opening a popover, or toggling password visibility.

Spinners show that background actions, such as loading or data fetching, are in progress.

Interactions

Mouse

Inputs can be activated when users click on their containers.

• Hovering over inputs changes the color and thickness of the input border.
• Clicking on the input focuses on it so users can begin typing.
• To interact with additional actions connected to the input, such as a password visibility toggle, users must click on the additional component.
• Focus is lost when users click away from the input.

Keyboard focus

• Tab: Navigates to and focuses on the input. Once the input is focused on, users can type into it. Users can also tab over to trailing buttons.
• Enter: Triggers an action when focused on a trailing button.
• Arrow keys: Move the cursor around inside the input.

Layout

The height of an input is predetermined and should not be changed.

The width of a field needs to match the content’s length.

• Don’t make an input too short to fit the expected entry.
• Give each field its own line unless they are short and related, such as the city, state, and ZIP code in an address.
• Inputs don’t have a set smallest or largest width, but don’t make fields that are smaller than the content that they’re collecting.
• The minimum recommended width is 120px on desktop and full width in mobile. This ensures that smaller inputs can be read and interacted with easily on touch screens.
• The maximum recommended width for inputs is 768px.