Since I wrote about building a show password component for GOV.UK I've started noticing other implementations online. Let's take a look at how they're built.
Before we start, here's what I'll be looking at in each of these examples.
- the HTML elements used
- how accessible it is, particularly for keyboard and screen reader users
- consideration for the slightly erratic support for autocomplete=off
- what happens when JavaScript is disabled
I'm going to be lazy and only test each example in one screen reader, but hopefully that will highlight any obvious problems.
Gmail
Gmail's show password option uses a checkbox wrapped in seven DIVs that includes the input label (a DIV, not a LABEL) wrapped in three more DIV elements. I like Google's products but their verbose approach to HTML is baffling.
The option can be used with a keyboard. I tested it quickly with VoiceOver and it recognised the checkbox and knew what it was called (despite its label not being a label) but activating it didn't do anything apart from tell me I'd checked the box - it didn't announce what had happened.
When the password is shown the input is updated with autocomplete=off, changing to current-password when the password is hidden.
Without JS the show password option doesn't appear.
Trello
Trello uses an SVG within a span to provide a clickable icon to show or hide your password.
The control isn't usable with a keyboard. VoiceOver doesn't recognise it as a focusable element, so it can't be used with this or probably any screenreader.
When the password is shown the input is updated with autocomplete=off, changing to current-password when the password is hidden.
Trello refuses to let you log in without JS enabled, so there's no need for any non-JS consideration on the show password option.
Facebook's show password option markup has a convoluted and unreadable style that is reminiscent of Google's. It uses a nested pair of DIV elements with an icon background wrapped in an A tag. It doesn't appear until characters have been entered into the password field.
It's possible to use the feature with the keyboard but it has no focus state.
There's no obvious catering for the autocomplete problem, but it seems to avoid it somehow. Confusingly if you fail to login correctly you're taken to a slightly different login screen, where autocomplete values are present on the password field.
Using VoiceOver, I'm told only that the show password option is a button. Toggling it informs me that I've pressed a button, but no other information is provided.
The show password option is invisible if JS is disabled but still appears in the DOM tree and seems to allow keyboard focus (but there's no focus state so it's hard to tell).
Twitter's show password option appears as a bit of text beneath the password input. It's a SPAN element wrapped in another span and various DIVs.
The wrapping SPAN has a role of button, and the option can be focussed and used successfully with a keyboard. Windows Narrator recognises it as a button but announces nothing when it is toggled. Interestingly, the password input has autocomplete="on", which I thought would have caused any password to be remembered, but I've been unable to confirm what effect this has.
Next
This one is bad.
Next's online shop show password option uses an anchor element (with an inline attribute JS call to what looks like a jQuery function).
Using this screen with a keyboard is a mess - the tabindexes are all over the place. The next focusable element after the password input isn't the show password option, but (ironically) a link to what looks like a separate, accessible version of the Next site (which also has obvious accessibility problems).
After seven more tab keys (via the header) focus returns to the show password option. It can then be used with the Enter key, but focus is immediately lost on keypress to somewhere else on the page.
VoiceOver predictably identifies the option as a link, and announces nothing when it is used. When activated it also loses focus on the element in the same way using it with a keyboard did.
There doesn't seem to be any consideration made for autocomplete attributes on the password field. When JS is disabled the show password option is still visible and non-functional.
Linkedin uses a SPAN element with a role of button, positioned to look as if it is over the password field.
VoiceOver identifies the element as a button. When toggled it announces that the button has been pressed, but nothing more. It can be used with a keyboard, and has a clear focus state.
The element is still visible but not functional when JS is disabled.
Instagram's show password option uses a button element that doesn't appear until you start typing your password.
It's usable with a keyboard. Although the text of the button changes to indicate the state, VoiceOver doesn't recognise this change, so pressing the button more than once only repeats "Show button".
It doesn't seem possible to get the browser to remember the password value as an autocomplete suggestion, although Chrome suggested 'password' during experimentation, which was odd. That's the label text, and the label wraps the input, so maybe it was confusing the two.
Without JS the page doesn't render.
The Australian Government
This one is really good.
The Australian Government's myGov site uses a button element positioned over the password field.
The button is usable with a keyboard and has some good screenreader accessibility, using aria-label to warn the user exactly what will happen when the button is pressed, and some visually hidden text to expand the text from 'show' to 'show password'. VoiceOver announced the password I'd written when the button was toggled.
The functionality wasn't present when JS is disabled. Autocomplete is successfully prevented on the password field.
eBay
eBay's show password option is a checkbox input wrapped in two SPAN elements wrapped in two DIV elements, positioned over the password field.
It's usable with a keyboard although the focus state is minimal. I tested it with Windows Narrator and it clearly identified the functionality on focus but nothing was announced when the checkbox was selected or deselected.
The password field has autocomplete=off. Without JS the functionality is present but doesn't work.
Thoughts
I can't draw many conclusions from this small sample of examples of this functionality, but there are a few things worth noting.
All of them use basically the same approach - an element that toggles the password field from type=password to type=text. An alternative might be to show the password in a different element, although I'm not sure if that's possible. As far as I can tell, all of them take account of the autocomplete problem, which is a win for security.
Consideration for whether JavaScript is disabled seemed to be less solid, although to be fair this is non-essential functionality and it's quite hard for non-developers to disable JS in their browsers these days.
The biggest problem for most of these sites was a lack of consideration for accessibility. Some sites didn't clearly convey the purpose of the show password option, and when used with a screen reader most of them didn't announce a change when it was used. Some didn't even have decent focus states for the option, even when using it with a keyboard was possible.