Simple things are complicated: making a show password option

After we launched the first GOV.UK Account trial on the Brexit Checker, we started receiving feedback from users, who requested an option to show their password when registering for and signing into their account. This would be particularly useful for users who experience difficulty when typing.

Adding a 'show password' option to GOV.UK Accounts seemed like a straightforward task, but the more we looked into it the more complicated and interesting it became. This is how we did it and some of the challenges we faced.

How to show a password

A password field is a text input with a type of 'password'. Browsers understand this and make the input behave in a specific way, for example, by obscuring the characters and preventing the contents from being copied.

Since this behaviour is handled by the browser, the only way to make a password visible is to change the input type from 'password' to 'text'. An alternative could be to duplicate the password outside of the input, where it would not be obscured, but this would require an additional level of complexity and might cause confusion to users.

We also had to decide how the user would control the 'show password' functionality. We considered 2 options - a button and a checkbox.

We wanted the control to clearly convey both the functionality and the current state, and to have some association with the password input. GOV.UK already has a checkbox style that is visually separate from other form elements, so rather than introduce a new style for an existing component, we chose to go with a button.

The button also required a type of 'button', to prevent it from submitting the form accidentally when used with a keyboard.

Changing an input type can only be done using JavaScript, so we also had to make sure that the button would not appear if JavaScript was disabled. This is an example of progressive enhancement - it's possible to sign in to an account without this, but the experience for users with JavaScript is improved.

Lessons:

• show or hide the password by toggling input type between 'password' and 'text'
• use a button with type 'button' to avoid accidental form submission
• disabled or broken JavaScript should not prevent the user from signing in

Keeping things secure

When you fill out a form online you might notice that suggestions of things you've previously submitted appear beneath some inputs, for example when typing in a postcode. This is called autocomplete, and it happens automatically.

Browsers make sure autocomplete doesn't happen for password inputs, as it could allow someone else using the same device to use your password. Instead, password managers allow users to store and manage their passwords as they choose.

If we showed the password by changing the password input into a text input, then the browser might remember its contents with autocomplete. We could have added an attribute to the input to set autocomplete to off, but this is not widely supported across different browsers and can have unpredictable results.

After discussion with the developer community from GDS and across government we decided to add some JavaScript to the component that would switch the input type back to password when its parent form is submitted. This returns everything to normal and prevents the browser from remembering the password as an autocomplete suggestion.

Lessons:

• don't allow users to submit text inputs containing passwords
• autocomplete="off" doesn't work in all browsers

Making sure it's accessible

It was also important to make sure that our 'show password' functionality was accessible to all users. We used aria-controls to associate the button with the password input. This attribute is not recognised by all screen readers, but it provides an enhancement for those technologies that support it. We also made sure that the functionality was accessible for keyboard users.

Screen reader users might not be able to see the password once it's shown, but they can still have it read to them. They also need to know something has happened when they press that button, and the current state of their password visibility.

Initially when the button was pressed we used the aria-live attribute on the password input to announce the password. This seemed like a good idea until we considered the security implications of a user doing this accidentally. Showing your password in a public space could allow someone in sight of the screen to read it, but making the screen reader announce your password could allow anyone within earshot to hear it.

To reduce this risk we added some hidden text and applied the aria-live attribute to that instead, so when screen reader users press the button they are told "your password is shown" or "your password is hidden". They can then choose to focus on the password input if it is safe to do so.

Lessons:

• allow assistive technology to understand what the button is for
• give the user control over whether their password is announced and inform them of the current state

Gathering user feedback

Making a 'show password' option seemed like a relatively straightforward task but turned out to have complex security and accessibility aspects. We're grateful to all of the people who helped contribute ideas and improvements to its development. You can see the component for yourself by visiting our component guide.

The 'show password' component is now live on GOV.UK Accounts and has allowed us to remove all 'confirm password' inputs. We'll continue to iterate it based on user feedback. If you have any thoughts or questions, leave a comment on this blog post or contact us using the feedback option on the GOV.UK Accounts trial.

EDIT: We've updated this post to remove the statement that modifying the text of a label is an automatic WCAG fail, as it is not. However, changing the setting of any user interface component that would cause a change of context without advising the user of the behaviour could result in a WCAG fail, and should be considered carefully.

We work in the open and we recognise the value of the wider scrutiny that this brings. Thanks go to Sara Soueidan for her feedback that led to this correction.