On the password field
Show password.
Put a control on the field.
See the characters before you submit. A second password box is not a substitute.
The short answer
Put a show-password control on the password field. An eye, or the word Show, with an accessible name such as “Show password”. Keep it on the field. Don't clear what they typed when they use it. Asking twice is a different problem.
Walk your signup
Why a hidden password costs the signup
The field shows dots. One wrong character looks the same as the right one. They notice when the account is refused, or they retype the whole thing and leave. On a phone the keyboard is small, the last character hides itself, and a pasted password is a guess. The check is a control on the field, not a second box they have to match.
What to put on the field
Put the control at the end of the password field, in the same row. Not in a menu, and not only after an error. Use an eye, or the word Show. When the password is visible, that same control says Hide.
Give it an accessible name: “Show password”, and “Hide password” once it is showing. The word Show on its own is a fine visible label when the name is the full phrase. Stumblet does not treat “Show” alone as a show control. A name the walker accepts is show password, hide password, reveal password, password visibility, show value, or hide value.
Don't clear the field when they toggle. Don't change the characters. Don't move focus out of the field. They are checking a typo, then editing it. The walk does not press the control, so it will not tell you if the value vanished. That part is yours to check.
One control covers this finding, even if the form has two password fields. If you also ask twice, drop the second field. Seeing the first is the check the second field was standing in for. Stumblet still flags them separately. A show control does not remove the confirm-password finding. Dropping the confirm field does not remove this one. The second field is on confirm password.
What Stumblet flags
1No show-password on “Password”
A visible password field, and nothing on the screen that shows the password. The title uses the field's label, as in No show-password on “Password”. The fix is “Add a show-password control on the “Password” field.” The line is “The “Password” field is here, and nothing on the screen shows the password.”
The field is the first visible one of type password, or whose label, name, placeholder, or autocomplete contains password or passcode. The label is those words, up to 80 characters, with asterisks removed. An empty label uses the placeholder, then the name, with underscores and hyphens turned into spaces. The first letter is capitalised. A trailing colon or asterisk is dropped. If nothing is left, the label is Password. The title and the fix shorten it past 32 characters. The line shortens it past 40. A hidden input is not a field. No password field means no finding.
A control counts when its text contains password visibility, show password, hide password, reveal password, show value, or hide value. Capitals do not matter. The phrase can sit inside a longer label. That control can be anywhere on the screen. It does not have to sit inside the password field. A button that only says Show does not count. An eye with no words counts only in the icon case below. A control whose text matches those phrases is not taken as the signup button.
Recorded controls are links with an href, buttons, submit and button inputs, role=button, onclick, and a class of button or btn, or a class starting with btn-. The text is the inner text, then the text content, then the value, then the aria-label, kept up to 140 characters. A class of button wrapped around a real button is not a second control. If none of those matched, a visible button or role=button is read again from its aria-label, its title, and that same text. The title is not used on the first pass, and it is not read on a link.
The icon case is a visible button or role=button whose parent contains an input of type password, whose own inner text is empty or a single character, and which contains an svg. An image or a font icon does not count unless the name matches the phrases. A link that is not role=button does not count as the icon. An input whose type is not password does not satisfy the icon case.
The check uses the screen as the walker reads it. If the password rules are not on the page yet, and the walker can focus a password field that is not a confirm field, it reads the page again after that focus. When the field is empty and the rules are still not visible, it types a test password before that second read. A show control on the screen at that second read is seen, and this finding does not fire. When it cannot focus one, the first read stands. If the rules are already on the page, there is no second read. A control that appears only after the fields are filled is not what this finding looks at. The rules check is on password rules.
The rank is 44. Missing password rules rank at 50, or 46 when the rule is only the placeholder, so the rules finding stays above this one. The report keeps five fixes at most. A hidden control does not count. The window is 1100 by 760, and the walk does not resize to a phone. It does not press the control.
Questions
Does a button that only says Show count?
No. The finding still fires. A control counts when its text contains password visibility, show password, hide password, reveal password, show value, or hide value. Capitals do not matter, and the phrase can sit inside a longer label. “Show” on its own is none of those. Recorded text is the inner text, then the text content, then the value, then the aria-label, kept up to 140 characters. The title attribute is not part of that text. Links with an href, buttons, submit and button inputs, role=button, onclick, and a class of button or btn, or a class starting with btn-, are recorded when they have that text. A class of button wrapped around a real button is not a second control. A visible button or role=button is read again if nothing recorded matched: the aria-label, the title, and the same text. “Show password” in the aria-label counts even when the word on the button is Show.
Does an eye icon with no words count?
Yes, in one case. It has to be a visible button or role=button. Its parent has to contain an input of type password. Its own inner text has to be empty or a single character. It has to contain an svg. That check uses the inner text, not the accessible name, so a long aria-label that does not match the phrases does not block it. An image, or a font icon, does not count unless the name matches the phrases. A link that is not role=button does not count as this icon, even with an svg. A link whose text matches the phrases still counts, because that text is a recorded control. The icon is the case that has to sit with the password input. A labelled control can sit anywhere on the screen. An input whose type is not password does not satisfy the icon case, even when its label says password or passcode. The phrases still do.
What if the form also asks for the password twice?
They are separate findings. A show control does not clear the confirm-password finding, and dropping the second field does not clear a missing show control. One matching control on the screen is enough here, even when there are two password fields. The title uses the first visible password field. A field of type password counts, and so does one whose label, name, placeholder, or autocomplete contains password or passcode. A confirm field matches that too, so if it comes first, its label is the one quoted. A hidden input is not a field. The second field itself is on the confirm password page.
What does the finding say?
The title is No show-password on “Password”. The fix is Add a show-password control on the “Password” field. The line is The “Password” field is here, and nothing on the screen shows the password. The words in quotes start from the label, up to 80 characters, with asterisks removed. If the label is empty, the placeholder is used. If that is empty, the field's name is used, with underscores and hyphens turned into spaces. The first letter is capitalised. A trailing colon or asterisk is dropped. If nothing is left, the label is Password. The title and the fix shorten that label past 32 characters. The line shortens it past 40. The rank is 44. Password rules that are missing rank at 50, or 46 when the rule is only the placeholder, so that finding stays above this one. The report keeps five fixes at most.
Does Stumblet press the show control?
No. It does not click the control. It does not check that the password becomes visible, that the characters stay, or that the cursor stays in the field. Keep the value when they toggle. Don't clear the field, and don't move focus out of it. The walk looks at a window of 1100 by 760. A control that is hidden at that size does not count: display none, visibility hidden, opacity 0, or a box no wider or no taller than one pixel. Below the fold still counts. A box parked off the left, above the page, or entirely to the right of the window does not. A control inside an aria-hidden region does not count, unless that region covers at least three quarters of the window, both wide and tall. The walk does not resize to a phone.
Asking for the password twice is on confirm password. Which fields to cut is on signup fields. What the first screen should say is on signup page copy. A button that stays disabled is on signup button. Showing the rules before anyone types is on password rules. Asking for a work email is on work email. A provider button above the email is on social login. Running it yourself, and keeping the top five, is the new-user signup test. The short list is the onboarding checklist. The AI onboarding audit is the walk, and the signup prompt is the job it runs.
The walk is free. It starts on the home page.
Walk your signup