Add guidance on show/hide password buttons #2861
Conversation
✅ You can preview this change here:
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Hey @calvin-lau-sig7! Claire and I are hoping to get your thoughts, eyes, and smarts on this PR, to see if it's good to go. No urgency though, as EtP work is likely your priority |
|
Could one button make the passwords in both 1st and 2nd fields visible? I'm surprised there's not guidance about whether to seek password confirmation or not |
| #### Showing and hiding passwords | ||
| One common method for helping users type passwords is a show/hide button near the password input. When the password is hidden, the button will change the input styling to 'show' the password. When the password is visible, the button will 'hide' the password again. | ||
|
|
||
| When there are two or more password fields on a page, the 'show' and 'hide' labels for each password input must be different. |
There was a problem hiding this comment.
Just stumbled across this and had a thought:
My understanding is that the reason many forms have two separate password fields is to ensure that the user has typed the password correctly, as they are unable to see it.
But by adding a show password toggle you no longer need to have two fields, as the user can validate the password is typed correctly by viewing it in plain text instead.
Do we actually need to provide guidance for multiple show/hide password toggles? Our guidance should probably push against having multiple password fields in the first place, as they are redundant entry.
There was a problem hiding this comment.
I'll just chime in on the question about relevancy to 'redundant entry' to note that there's an exception carved out specifically for security. Typing a password and reducing keystroke errors in that password through redundant entry seems like a good use of that exception.
As far as I understand it. the intent of 'confirm password' inputs is to ensure that the person doesn't mis-type one of the entries. Since many people may type without carefully reading the password, even if it's visible on the screen, it'll be valuable even if they can visually see the password characters. Additionally, some people may be in an environment where showing sensitive information like a password or password confirmation on-screen is a security risk. So it's still best to have the hidden characters as the default.
There was a problem hiding this comment.
My comment was related to articles such as https://uxmovement.com/forms/why-the-confirm-password-field-must-die/
And secondly that providing the password reset feature works well (and you enter your actual email address which is ensured by authentication), it doesn't matter if you enter the password as you intended.
I'm not necessarily advocating a particular stance on this, just expressing surprise that there doesn't seem to be a pattern or guidance on the issue here as I expected.
Co-authored-by: Calvin Lau <77630796+calvin-lau-sig7@users.noreply.github.com>
Related to this issue: