Password input
andysellick opened this issue · 17 comments
Use this issue to discuss this component in the GOV.UK Design System.
Original contribution submission
A 'show password' component. Consists of:
- password input field for user to enter their password
- control to toggle the visibility of the text in the input
Why
This is a component that has been used successfully on GOV.UK Accounts. The component was created after user research suggested it would be useful, and has since featured in user research sessions. Specifically:
- prior to implementation we received a support ticket from a user with arthritis requesting the feature (see below)
- in recent user research, a user (who used a screen magnifier and reversed colours) was using a password and password confirm fields without the feature, they said that normally they would look for this feature to ensure they had typed what they thought they had typed
This does not appear to be on the Design System yet and I couldn't see it on the backlog. However showing a password is mentioned on the text input component: https://design-system.service.gov.uk/components/text-input/
Anything else
Current version in use on GOV.UK: https://components.publishing.service.gov.uk/component-guide/show_password
Can't link to the research mentioned above directly but can share on request.
More information about the component: https://technology.blog.gov.uk/2021/04/19/simple-things-are-complicated-making-a-show-password-option/
Thanks for sharing this component and adding it to the community backlog @andysellick!
The Design System team are currently working through a backlog of contributions, as well as assessing what will be the priority contributions over the next 12 months. We'll be in touch when we can progress this further. In the meantime, teams across government can benefit from the work you have done via this backlog entry. Thanks again!
Realised I submitted this a while ago and wanted to provide an update. I found out recently that this component is now being used in a number of places by the DI team, who've found it very useful. I'm very happy to progress this, is there any appetite for adding it to the Design System?
There are some related things happening in the CSS Basic User Interface Module Level 4 spec that are worth being aware of.
After a proposal to add a new CSS property input-security to control the masking of passwords back in 2018 (which references Andy's blog post!) there is now a note on the spec that suggests this is now being removed from CSS+JS in favour of it being implemented in user agents.
However, there's another discussion on whatwg/html which highlights some of the challenges in making that a reality, including a link to an interesting Chromium bug #1016844 where this has previously been tried.
Chromium #991878 Also looks like it's worth following.
Hey @andysellick 👋🏻 Sorry for the long wait for a response. A quick update on this:
For our work on the design system accessibility strategy, part of this being to meet WCAG 2.2, we've kept an eye on this component and think it could help us cover criterion 3.3.7. We're basing this on the understanding document and the following paragraph in the 'intent' section:
Another factor that can contribute to cognitive load is hiding characters when typing. Although this criterion requires that users do not have to type in (transcribe) a password, there are scenarios where that is necessary such as creating a password to be saved by a password manager. Providing a feature to optionally show a password can improve the chance of success for some people with cognitive disabilities or those who have difficulties with accurately typing.
We're currently working through prior contributions however it's likely we'll pick this up once we start working on WCAG 2.2 compliance in 2023. If you have any questions and/or wanted to discuss this prior to an official kick off of this work, the team would be happy to chat to yourself and any interested parties from One Login (CC @gtvj).
Thanks @owenatgov that's really great to hear. Totally appreciate how busy you've all been. If there's anything I can do to help this process along at any point please let me know - I'd be very happy to contribute.
As something not-yet-noted for the record, we may need to ensure that any solution doesn't conflict with password managers (both built-in and third-party ones) which may offer similar functionality or also manipulate the appearance of password inputs.
For example, Safari inserts its own button into the input if a password has previously been saved.
1Password, a third-party password manager, does the same.
Some versions of Microsoft Edge on Windows also used to have a 'show password' control implemented in the user agent, but I believe this has since been removed (edit: nope, it's still there!)
The account and auth teams in Digital Identity are using this component created by @andysellick on our frontends, so as far as we are concerned it would be a useful addition to govuk-frontend.
Looking forward to seeing this component in DS. In DWP, our login and identification service allows users to create an account and verifty their identity through HMRC IV. We have done many rounds of user research on our journeys and few users asked why we don't have a mechanism for them to show/hide their password.
We ran an external accessibility audit for some of the components and patterns in GOV.UK Frontend in May 2023. In that audit, we included an example of the Password component. We’re adding results from that audit here so that we can:
- document, discuss and address the findings
- inform future contributors of the findings
One WCAG AAA issue raised
When there's 2+ password fields on a page, the 'show' and 'hide' labels need to be different
Both of the ‘Show’ buttons presented for users have been provided with an ‘aria-label’ to offer users of screen reading assistive technologies additional context that they are to show the password. However, both buttons have been provided the same name of ‘Show password’, meaning that screen reader users are not able to distinguish which button relates to which field.
This same occurs when the button is activated, and the label is changed to ‘hide’.
More detail in this issue:
VoiceOver Bug with a hidden "show/hide" password field
What
Expected Behaviour:
When using the VoiceOver screen reader with Google Chrome on MacOS. When the password field is hidden and if your input is more than 13 characters, it should read out the entire character length.
Actual Behaviour:
When using the VoiceOver screen reader with Google Chrome on MacOS. When the password field is hidden and if your input is more than 13 characters, it splits the character length (e.g. "13 characters, 8 characters" as shown by the screenshots attached below).
Steps to Reproduce
- Go to any sign page.
- You can just enter the user id and more than 13 characters of the password and keep it hidden.
- Enable VoiceOver via Settings.
- Use ⌃+⌥+A to enable VoiceOver and reach up to the password field.
Why
As of writing this, there is currently no explainable cause.
Sources
Environment (where applicable)
- Operating System:
MacOS Ventura (13.5) - Browser:
Google Chrome - Browser Version:
Version 115.0.5790.114 (Official Build) (x86_64) - GOV.UK Frontend Version:
4.7.0
Have been attempting to find some more user research on this component and it is used by the One Login programme in a few places. Making a note of some links here for future refence.
- Pages with 2+ password fields must use different programmatic labels for 'show' and 'hide' buttons on those password fields (issue raised)
- Accessibility audit where this issue was found
This user research hasn't specifically focussed on the show password component (i.e. users weren't asked directly how they feel about it, although there has been discussion around password managers) but no users mentioned it during research on the pages where it featured.
Hi,
This component should also consider security implications particularly around "spell-jacking" and browser spellcheckers reading passwords. The spellcheck=false should be on the component, but it might also be worth covering implications in any supporting documentation too.
We’ve started work on this component as part of the WCAG 2.2 work we’re doing. The epic that shows how we’re breaking down the work is here: alphagov/govuk-frontend#4063
We've just added some guidance on how to 'share findings about your users' with us 📝. This will help us learn more about how your users show and hide passwords within your service.
This is similar to MOJ's password reveal component. I'm hoping the MOJ team can share some insights so we can pool those with learnings from GOV.UK Accounts and GOV.UK One Login.
Just checking in here to see if there is an ETA on this. Also, curious about the feedback on the MOJ's example.
Also, since this is a toggle, would be to make sure the confusion described here by Leonie Watson isn't replicated.
https://www.youtube.com/watch?v=OUDV1gqs9GA&t=3219s
Usefulness of a second password input for confirming a password
Problems we wanted to solve
Whether including a second password field input, also known as a ‘confirm password’ field, is beneficial for users creating a password.
What we decided
After doing research we decided that having a second field is not helpful for users, particularly on password inputs with show and hide buttons.
Our rationale
Retyping a password puts additional cognitive load on a user. They’re required to remember and in some cases input the password in without using the paste function. If the paste function is turned off, this is a fail against WCAG 2.2 success criterion 3.3.8 Accessible Authentication (Minimum).
A form builder tool reported that the confirm password field was responsible for over 25% of users that leave a form without completing it. Removing the confirm password field improved completion rates, along with other conversion metrics, with no change in password reset requests.
Finally, users can use the password reset function if they are unable to remember their password correctly.
Considerations we made
Security, recollection and lack of visibility have been the traditionals reasons for having a second password input field.
The user might feel more confident by having to type their password twice, as they may be concerned they’ve entered it incorrectly. Users may also use a simpler password in order to assist their recollection and mitigate the chances of them incorrectly entering it.
A second password input field can be useful for users to check for mistakes in their password, but only if the user avoids using copy and paste to fill the confirm password field.
Users in public settings might not feel comfortable showing their password on the screen, and prefer another method to check the password they’ve entered. However, we felt these scenarios were too specific, especially when there are other things the user can do.
If both fields are hidden when entering the password, the user might not know whether they’ve entered the password incorrectly. By allowing users to see their password using the show password input, the user can spot any mistakes and fix them.
Results
We’d like to establish if our rationale is supported by real life examples, and ask service teams for feedback to see if this is the case.
We’re aware that Understanding SC 3.3.8: Accessible Authentication (Minimum) advocates for a show/hide functionality, stating:
Providing a feature to optionally show a password can improve the chance of success for some people with cognitive disabilities or those who have difficulties with accurately typing.
However, WCAG does not mention anything on the relationship between having a show and hide functionality along with two password fields.