Autocomplete in Modern Browsers

At WWDC 2014, Apple presented an interesting talk about extending the interaction between native iOS apps and the Web. Buried late in the presentation was a tiny nugget of goodness about using the autocomplete attribute on form elements to help signal your form’s intent to the browser; specifically MobileSafari 8, coming soon in iOS 8. This has important benefits to any version of Safari (and other standards-centered browsers) because there are new values possible in the W3C spec that any browser can use to present a much nicer user experience.

Safari in Mavericks already provides tools to help users create and manage randomized passwords for each site they visit. While this talk was primarily centered on using this mechanism to provide cross-media experiences (sign up on the Web, use the same credentials in a native app) it gave some fascinating insights into how Safari uses autocomplete — how it infers what data to put in each field. And it gave some important information about how to explicitly signal your intent to the browser, so this process could be less ambiguous.

Recently, new autocomplete attributes were ratified by all of the standards bodies. This means that implementing Safari 8’s approach will have progressive enhancement benefits to the other browsers as soon as they join the party.

So the first place to use this is in any sort of login screen. Adding the attribute autocomplete="username" to the username (or email) field signals which credential Safari should present there, and also signals that the next field, labeled wth autocomplete="current-password" should be the matching password for that site.

When a user logs in for the first time using a Mavericks or greater Safari, the system will offer to create a highly nonsensical one-use password, and save it in the Keychain for return visits. The user doesn’t need to fuss with a third-party password manager, or worse, re-use a credential that may already have been compromised in one of the many widely-publicized site break-ins. Only the master Keychain password needs to be remembered, and on a single-user Mac or iOS, the device itself becomes the key.

A common pattern in signup forms is to ask the user to repeat a credential in order to piss them off make sure they really meant it. It is important to label both fields with the same appropriate autocomplete value so that Safari gets the best idea of your intent.

When it comes time to change the password, labeling the fields properly ensures that this stored password will be updated in the Keychain, rather than an entirely new credential being created.

Whenever you are changing a password, it is very important to also include the username in the same form, so that the correct account will be updated in the Keychain. If you don’t want to have the field visible, as it is here (marked with readonly so it doesn’t get changed inadvertently) you can also use a hidden field to the same effect.

Instead of current-password, you use new-password as the field’s autocomplete property, and Safari will understand that the intent is to create a new password. This allows you to have multiple password fields on the same page (perhaps you require the old password in order to change to a new one in your form) without confusing Safari.

I believe this is an important standard to jump on and implement everywhere. Giving the browser a better idea what you are asking the user for can only help the form be more useful and usable for everyone. The wider use these attributes receive, the more browsers will support them, completing the virtuous circle.