Use password creation when a user must choose a new reusable secret; use password input for entering an existing secret, inline validation for field-level creation feedback, and error summary for reachable recovery after submit.
Use password creation when a user must choose a new reusable secret; use password input for entering an existing secret, inline validation for field-level creation feedback, and error summary for reachable recovery after submit.
Practice the judgment: Imagine this situation: A form blocks password-manager paste or generated passwords, so users choose a weaker secret they can type manually. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Password creation | Password input | Inline validation | Error summary |
|---|---|---|---|---|
| UI or UX | UI + UX - New authentication secret selection flow | UI + UX - Authentication secret entry control | UI + UX - Field-level validation feedback | UI + UX - Form recovery summary |
| UI guidance | Keep the guidance focused on what actually affects acceptance: length, banned or breached value checks, service-specific terms, and password-manager compatibility rather than a decorative checklist of character classes. | Render password entry as a labelled password field that is hidden by default, uses the correct autocomplete purpose, offers a clear show and hide control, disables spellcheck and automatic capitalization, and keeps helper and error text connected to the input. | Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state. | Render a top-of-form summary block with heading, linked error list, and matching field-level error messages. |
| UX guidance | Use password creation when a user is choosing a new reusable secret during registration, password reset, first-time setup, or password change. | Use password input when a user enters an existing secret to sign in, reauthenticate, unlock a protected action, or confirm account ownership. | Help the person reach a clear task outcome. | Move users from the summary to the exact field, group, or first invalid control that needs correction. |
| Good UI | A signup form labels the field New password, uses autocomplete new-password, allows password-manager generation, says Use at least 15 characters or a generated password, and rejects Password123 because it is commonly used. | A reauthentication dialog asks for Current password, lets the user show it temporarily, accepts a pasted manager value, and clears the field after an incorrect attempt. | Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible. | Top-of-form summary with a clear heading, linked error list, and matching inline field messages. |
| Bad UI | A reset form asks for a password reminder question and then emails the new password to the user. | A login form uses a normal text field named Password and leaves the secret visible on screen. | Error message appears far from the field it describes. | Summary and field messages visually disconnected or contradictory. |
| Good UX | The person reaches the intended result with clear feedback. | The person reaches the intended result with clear feedback. | Validation appears after blur or submit when it helps correction. | After failed submit, focus or reading order makes the summary discoverable before users scan the form. |
| Bad UX | A user is forced to rotate a password every month and chooses predictable variations that are easier to guess. | A failed login page says the password is wrong, confirming that the username exists. | Showing errors before users type. | Only showing errors below the fold. |
| Best fit | The user is creating an account with a reusable password. | The user needs to enter an existing password, passphrase, or PIN-like memorized secret. | A single field has a specific correctable problem. | Form submission can produce one or more errors. |
| Avoid when | The user is only entering an existing password to sign in or reauthenticate. | The task is choosing a new password and needs creation-specific guidance, strength feedback, and blocklist rejection. | The main recovery task is finding several errors across a submitted page. | The message is a system failure, permission problem, or outage rather than a validation issue. |
| Required state | Too-short state with the entered value preserved and a field-level length message. | Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control. | Invalid field with preserved user value and adjacent correction text. | Failed-submit state with summary visible near the form heading. |
| Accessibility burden | Use a visible label that says New password or Create a password rather than only Password when the user is choosing a new value. | Use a visible label that names the password purpose, such as Password or Current password. | Expose invalid state on the input and connect error text to the field description where possible. | Use a heading and alert behavior that makes the summary discoverable. |
| Common misuse | Using uppercase, lowercase, number, and symbol checklists as the main security signal. | Using type text for passwords. | Showing field errors before users have interacted with the control. | Replacing field-level messages with only a top-level summary. |