Input "password"

Interaction methods

The password starts hidden and the button displays "Show password".

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.

Show and hide the password

1. With the password hidden, clicking, tapping, or pressing Enter or Space on the "Show password" button reveals the content and changes the text to "Hide password".
2. With the password visible, activating "Hide password" masks the content again and changes the text to "Show password".
3. The button has type button, does not submit the form, and keeps focus after activation. The field value is preserved.
4. The accessible name follows the text of the next action. In this changing-label pattern, use an action button without aria-pressed. The screen reader should not receive extra announcements containing the password.

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 "password"

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 and characters remaining hidden by default
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 a password field.
   • I HEAR the required status, instructions, and associated errors, when present.
   • I HEAR that entry is protected while the password is hidden, without extra announcements of the password content.
2. THEN, when I type or edit content using native commands
3. I HEAR or perceive that I can edit the field according to the platform's protected entry behavior, without exposing the password in status messages.

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 a password field.
   • I HEAR the required status, instructions, and associated errors, when present.
   • I HEAR that entry is protected while the password is hidden, without extra announcements of the password content.
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 according to the platform's protected entry behavior, without exposing the password in status messages.

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

Show and hide the password by keyboard

1. WHEN I use Tab to move focus to the "Show password" button while the password is hidden
2. The focus I SEE is strongly indicated visually
3. THEN, when I use Enter or Space to activate the button
4. I SEE the password in visible text and the button now displays "Hide password"
5. AND I SEE the value preserved and focus staying on the button without submitting the form
6. THEN, when I use Enter or Space again
7. I SEE the password hidden again and the button now displaying "Show password", preserving value and focus without submitting the form

Password visibility with a desktop screen reader

1. WHEN I use Tab to focus the visibility button while the password is hidden
2. I HEAR that the component is a button named "Show password"
3. THEN, when I use Enter or Space to activate the button
4. I HEAR or perceive that the button's name changed to "Hide password" and focus remains on the button
5. THEN, when I activate the button again
6. I HEAR or perceive that its name returned to "Show password" and focus remains on the button
7. The password value is preserved and the form is not submitted; the password is not included in extra announcements or status messages

Password visibility with a mobile screen reader

1. WHEN I swipe to focus the visibility button while the password is hidden
2. I HEAR that the component is a button named "Show password"
3. THEN, when I double-tap or use the appropriate gesture to activate the button
4. I HEAR or perceive that the button's name changed to "Hide password" and focus remains on the button
5. THEN, when I activate the button again
6. I HEAR or perceive that its name returned to "Show password" and focus remains on the button
7. The password value is preserved and the form is not submitted; the password is not included in extra announcements or status messages

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. Allow pasting and password managers. Use autocomplete="current-password" for sign-in and "new-password" for password creation. Hiding characters does not replace data protection.

Text button and optional icons

1. This pattern uses "Show password" while content is hidden and "Hide password" while it is visible.
2. You can use an open or closed eye icon: an open eye to show content and a closed eye to hide it. The icon represents the available action, matching the button's text.
3. Prefer Material Icons: visibility to show and visibility_off to hide. If the icon accompanies text, hide it from assistive technologies using aria-hidden="true".
4. If using only an icon, provide the accessible name "Show password" or "Hide password", updated to match the available action.
5. Do not block pasting or autofill. Do not log the password or include it in status messages.

References

Field documentation

• MDN — input type="password" (external link, opens in a new tab)

Design System

• GOV.UK — Password input open_in_new (external link, opens in a new tab) — Specific component with a text button to show and hide the password.
• Carbon — Text input: Password input open_in_new (external link, opens in a new tab) — Password variation with an icon visibility control.
• Bootstrap — Form controls open_in_new (external link, opens in a new tab) — Password field and associated instructions; this example does not include a visibility button.