WHEN I use the tab key to move focus to the password input
I SEE focus is strongly visually indicated
Then when I use the tab key to move focus to the show/hide password feature
I SEE its name, role and state
Then when I use the show/hide password feature
I SEE the state of the password visibility (with or without characters entered)
2 Desktop screenreader
WHEN I use a desktop screenreader (NVDA, JAWS, VoiceOver)
AND
I use the tab key to move focus to the password input
I HEARIts purpose is clear
I HEARIt identifies itself as a text input
I HEARHints or errors are read after the label (Ex: Password formatting)
I HEARIt expresses if the password is being shown and if applicable: required, disabled / dimmed / unavailable
Then when I use the tab key to move focus to the show/hide password feature
I HEARits name, role and state
Then when I use the show/hide password feature
I HEARthe state of the password visibility (with or without characters entered)
3 Mobile screenreader
WHEN I use a mobile screenreader (Talkback, VoiceOver)
AND
I swipe to focus on a password input
I HEARIts purpose is clear
I HEARIt identifies itself as a text input
I HEARHints or errors are read after the label (Ex: Password formatting)
I HEARIt expresses if the password is being shown and if applicable: required, disabled / dimmed / unavailable
1 Keyboard & screen reader actions
When I use
I see/hear
Tab
Focus moves visibly to the input or show password checkbox
Spacebar
Toggles the show password checkbox
2 Mobile screenreader gestures
When I use
I hear
Swipe
Focus moves to the input
Keyboard
Keyboard appears
3 Screenreader output for all devices
Reads
I hear
Name
Its purpose is clear
Role
It identifies itself as a text input
Group
Hints or errors are read after the label (Ex: Password formatting)
State
It expresses if the password is being shown and if applicable: required, disabled / dimmed / unavailable
A
password input
must meet these WCAG principles.
1Perceivable
Is easy to identify as interactive
Color is not used as the only means of conveying information
2Operable
Is keyboard operable
The click/tap target area is no smaller than 44x44px
The disabled and focus states have a 3:1 minimum contrast ratio against default
The focus indication has a 3:1 minimum contrast ratio against adjacent elements
The focus indication has a minimum area equal to the width of the element and 2px in height
3Understandable
Its purpose is clear in the context of the whole page
4Robust
Conveys the correct semantic role
Expresses its state
Meets criteria across platforms, devices and viewports
Code examples
Checkbox variant
This semantic HTML contains all accessibility features by default.
Placing the show password checkbox ahead of the password input increases discoverability for screen reader users.
CSS pseudo elements are used in the checkbox label to express its state on focus of the password input.
Button variant
The button leads the input so screen reader and keyboard-only users can change the state before interacting with the field.
The password field type toggles between type of password and text.
A live region role="status" is used to automatically announce to screen reader users the current visibility of the password value. For example, “Password is currently visible”.
Avoid adding aria-hidden="true" or CSS display: none; to the live region container that receives the dynamic update as this may impact screen reader support.
Ensure the dynamic text, that is added to the live region, is removed from the DOM after a short amount of time so screen reader users do not encounter this text while navigating beyond the form field.
Developer notes
Name
Include for="input-id in each <label> label to associate it with the input
Use aria-label="Input name" as a last resort if a <label> can’t be used
Role
Identifies as some kind of secure input [or text when toggled to text]
State
The show password checkbox must indicate its state on focus
Group
Include for="input-id in each <label> label to associate it with the input
Use <fieldset> and <legend> to name a group of inputs.