Select your language
Select other languages

Automatic translation

Loading translator…

Magoomake your components work correctlyBack to homepage

Input "email"

Allows entering an email address.

For working examples and design patterns for this component, see the references tab (opens the references on this page).

COMPONENT GUIDE

Explore behaviors before defining the interface.

Quick guide for designers

Always consider the context of the application, even when the guidance follows a standard pattern. Interaction design documents intent. Behavior must be verified in the implementation.

When to use

Use to enter an email address. Format validation does not prove the address exists.

What to draw

Show a persistent label, format hint, focus, and filled and error states.

How it behaves

The person edits and pastes text normally. On error, preserve the value and explain the correction.

What to document in Figma

Record required status, messages, and Enter behavior. If multiple addresses are accepted, explain how to separate them.

How to review

Check whether the purpose and states are clear on small and large screens and with zoom. Verify documented behavior in the implementation, including keyboard and screen reader use where applicable.

Full guidance

Interaction Design

Questions to ask when designing Input "email" components.

Assess each guideline according to the component's context of use.

Designing for "no interaction"

  1. Does the label remain visible and explain the field's purpose?
  2. Are instructions, required status, and limits available before entry?
  3. Are empty, filled, invalid, disabled, and read-only states distinguishable without relying solely on color?

Designing for mouse use

  1. Does clicking the field or its associated label focus it for typing?
  2. Do focus and associated controls provide perceptible visual feedback?

Designing for gesture use

  1. Does the touch area allow selecting the field and its controls without accidental activation?
  2. Do the virtual keyboard and zoom allow the field to remain visible and editable?

Designing for keyboard use

  1. Tab and Shift + Tab move through controls in interface order?
  2. Can you edit and select text using native commands without trapping focus?

Designing for screen reader use

  1. Are name, type, required status, instructions, and errors presented understandably?
  2. Is the label associated with the field and still available after filling it in?

Interaction methods

The field uses type="email" and, on compatible devices, offers an appropriate email keyboard.

Mouse interaction

  1. Clicking the field or its associated label puts focus in the field.
  2. Selecting, editing, copying, and pasting follow the field's native behavior.

Keyboard interaction

  1. Tab moves focus to the field; Shift + Tab returns to the previous control.
  2. Typing inserts text; arrow keys, Home, End and selection and editing commands follow the platform.
  3. Enter follows the form's defined submission action; the field does not create a new line.

Gesture interaction

  1. Tapping the field or label allows editing with the virtual keyboard.
  2. Text selection and editing follow the platform's available gestures.

Keyboard (or gesture) interaction + screen reader

  1. When navigating to the field, the reader presents its label and type, along with associated states and instructions.
  2. Errors are associated with the field and explain how to correct the information; the entered value is preserved.

Gherkin

BDD (Behavior-Driven Development) methodology focusing on three pillars: User Stories, Acceptance Criteria, and Gherkin Syntax (Given, When, Then).

Scenario: Given that I am on a page containing Input "email"

Keyboard navigation

  1. WHEN I use the Tab key to move focus to the field
  2. The focus I SEE is strongly indicated visually
  3. THEN, when I type, select, or edit content using native commands
  4. I SEE the field value updated
  5. AND, when I use Tab or Shift + Tab, I SEE focus follow page order without getting trapped in the field

Desktop screen reader

  1. WHEN I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and use the Tab key to move focus to the field, the following happens:
    • I HEAR the field's label and purpose.
    • I HEAR that the component is an email field.
    • I HEAR the required status, instructions, and associated errors, when present.
  2. THEN, when I type or edit content using native commands
  3. I HEAR or perceive that I can edit the field and that its value was updated.

Mobile screen reader

  1. WHEN I use a screen reader on a phone (TalkBack, VoiceOver) and swipe to focus the field, the following happens:
    • I HEAR the field's label and purpose.
    • I HEAR that the component is an email field.
    • I HEAR the required status, instructions, and associated errors, when present.
  2. THEN, when I double-tap or use the appropriate gesture to activate the field and edit its content
  3. I HEAR or perceive that I can edit the field and that its value was updated.

Input validation

  1. WHEN an entry is rejected by a stated validation rule
  2. I SEE a message associated with the field explaining how to correct the information
  3. AND, when I navigate to the field with a screen reader, I HEAR the error indication and associated guidance
  4. THEN, when I edit again, I SEE the value preserved for correction

Email format

  1. WHEN I submit a value with an invalid email format
  2. I SEE or HEAR guidance on correcting the format
  3. Format validation does not prove the address exists

Considerations

  1. Use a persistent label associated with the input. A placeholder is a supplementary hint and does not replace the label.
  2. Associate instructions and errors with the field, for example using aria-describedby, and set aria-invalid when there is an error.
  3. Indicate required status and use required when needed. Do not communicate errors solely through color.
  4. Keep focus visible and ensure adequate contrast and interaction area.
  5. Format validation does not prove the address exists. Accept a single address by default; use multiple only if the context requires several addresses and explain how to separate them.

References

Field documentation

Design System

Original content by Marcelo Sales, initially used in the AccessBoost course (external link - opens in a new window). These interactions represent standard industry patterns, but may be customized in specific cases, provided there are sufficient instructions for people to understand the behavioral change.