Email address entry

Problem Context

• The service needs to send receipts, status updates, invitations, alerts, reset links, verification messages, or account notifications.
• Users may have multiple addresses and need to know whether to give work, personal, recovery, shared, or temporary email.
• Addresses may include plus tags, subdomains, long domains, uncommon top-level domains, uppercase letters, dots, hyphens, and pasted whitespace.
• A syntactically valid email address does not prove that the user owns or can access the mailbox.
• Wrong addresses can leak information, block recovery, prevent receipts, or send a message to another person.

Selection Rules

• Choose email address entry when the field value must be an email address used for contact, identity, invitation, recovery, notification, or receipt delivery.
• Use type email, autocomplete email, spellcheck false, and a visible label that says Email address or names the mailbox purpose.
• Explain why the address is needed unless the purpose is already obvious in a sign-in context.
• Allow paste, browser autofill, plus addressing, subdomains, long addresses, and uncommon domains.
• Size the field so most users can inspect at least the main part of the address, and support up to 254 characters.
• Validate empty and malformed values after blur or submit, preserve the entered value, and say how to fix it.
• Trim accidental leading and trailing spaces, but do not silently rewrite the local part, domain, or provider.
• Warn on likely provider typos and offer a suggested domain, but let users keep the original address.
• Use the multiple attribute only when the task truly accepts multiple comma-separated addresses; otherwise reject multiple addresses clearly.
• Show the captured address on review or confirmation before sending consequential email.
• Use an email confirmation loop only when the service must know that the user can access the mailbox.
• Do not require repeated email entry, block paste, or force confirmation loops unless research and risk justify the extra friction.

Required States

• Initial state with label, purpose hint, type email, autocomplete email, spellcheck false, and adequate width.
• Focused state with email keyboard and normal typing, paste, selection, undo, and autofill behavior.
• Pasted address state preserving plus tags, case where relevant for display, subdomains, and long domains.
• Missing required email state with field-specific error text.
• Malformed email state with an example such as name@example.com.
• Likely provider typo warning state with change, keep, or suggested-domain action.
• Multiple addresses rejected state when only one address is allowed.
• Long address state where enough of the value can be inspected and no silent truncation occurs.
• Reviewed address state with change action before receipt, notification, recovery, or invitation is sent.
• Email confirmation pending state when access to the mailbox must be proven.
• Delivered or verified state that records contactability separately from syntactic validity.

Interaction Contract

• Users can type, paste, autofill, edit, select, undo, and correct the email value through native input behavior.
• Submitting an empty or malformed address keeps the typed value and puts the correction next to the field or in a linked summary.
• Provider typo warnings are advisory and never overwrite the user's value without confirmation.
• Review states show the exact address that will receive messages and provide a direct change path.
• Confirmation loops explain what was sent, where it was sent, how long the code or link lasts, and how to change the address.
• The backend treats syntax validity, deliverability, ownership, and verified access as separate states.

Implementation Checklist

• Use a native input with type email, autocomplete email, spellcheck false, a stable label, purpose hint, and aria-describedby for hint, warning, and error text.
• Support paste, autofill, mobile email keyboard, long values, plus tags, subdomains, uncommon domains, and copied addresses with leading or trailing spaces.
• Validate required and email-format errors on the client and server, and avoid brittle regular expressions that reject real addresses.
• Add provider typo detection for common domains only as a warning with keep and change paths.
• Use a review page, summary row, or confirmation panel before sending important email.
• Use email access confirmation only for account activation, password reset, sensitive notifications, or flows where mailbox access is required.
• Test password managers, browser autofill, paste, mobile keyboard, screen readers, zoom, long addresses, plus tags, multiple-address attempts, provider typos, bounced email, and confirmation timeout.

Common Generated-UI Mistakes

• Using a plain text input without email autocomplete or email keyboard support.
• Blocking paste or browser autofill.
• Rejecting plus-addressed, long, subdomain, or uncommon-domain addresses with a narrow regex.
• Silently correcting a provider typo and sending mail to the changed address.
• Asking users to repeat the email address without evidence that it helps.
• Forcing an email confirmation loop for low-risk contact or receipt fields.
• Hiding the entered address so users cannot review it before a reset link or receipt is sent.
• Treating syntactic validity as proof that the mailbox exists or belongs to the user.

Critique Questions

• What will the service send to this email address and how should users choose which mailbox to provide?
• Does the field use type email, autocomplete email, spellcheck false, and enough visible width?
• Can users paste or autofill plus-tagged, long, or uncommon-domain addresses without rejection?
• What happens when a user enters a likely provider typo such as gmial.com?
• Does the flow need mailbox access confirmation, or is review and change enough?
• How are format validity, deliverability, bounced messages, and verified access represented separately?