Implementing HTML 5.2 into the user create and edit forms.

[derweili]

With the autocomplete attribute, we can specify what information the user-agent must provide when (auto-)filling form field values, and provide guidance to the browser about the type of information expected in the field.

Using the autocompletion attributes results in better UX and accessibility.

By now the autocomplete attribute is not used for the WordPress User Login/Signup/Edit forms. (except for the password-field where it is disabled)

Example improvement:
By implementing the HTML autocomplete attributes we could tell the user-agent to input a new password on the signup page and to use an existing password on the login page. This info can then be used by the browser, Password-Managers or assistive technology to provide the appropriate information.

More information can be found on the ​https://www.w3.org/TR/WCAG21/#input-purposes

I would recommend to use following autocomplete values for following forms:

suggestion

Login Form

Form Field	Autocomplete Value
Username/Email	TBD
Password	current-password

Lost password form

Form Field	Autocomplete Value
Username/Email	TBD

Password Reset Form

Form Field	Autocomplete Value
New Passwort	new-password

Add new User / Edit User / Edit Profile - forms

Form Field	Autocomplete Value
Username	username
Email	email
First Name	additional-name
Last Name	family-name
Website
Password	new-password
Nickname	nickname

Register form

Form Field	Autocomplete Value
Username	username
Email	email

I'm currently not sure what autocomplete value to use for the Username/Email field on the login and lost password forms.
These fields support username as well as email, but the autocomplete attribute does not support multiple values yet.

[SergeyBiryukov]

Possibly related: #24364, #35707, #43886.

[bookdude13]

I think this is a good idea to do, my concern is ​| browser support. Right now password values set to autocomplete=off are ignored by most browsers (since they like to offer the built-in password manager). new-password is mostly supported, but not by IE (see ​https://caniuse.com/#feat=mdn-html_global_attributes_autocomplete_new-password). I don't know about support for other values, but in my opinion new-password and current-password would be the most useful and their support is not high enough at this time to implement. Once browsers catch up or we drop IE support, then I think this should be revisited.

[derweili]

@bookdude13 I don't think browsersupport is a problem. The autofill attributes are backwards compatible.

If a browser finds a unknown attribute, it is ignored by the browser.

So we can add this attribute which results in better user experience in new browsers without breaking anything in older browsers.

Did I missing something?

[bookdude13]

Whoops yeah you're right, backwards compatibility isn't an issue.

[afercia]

This ticket was discussed two weeks ago during the weekly accessibility bug-scrub on Slack. Sorry I missed to report some feedback. Here it is :)

@derweili thanks for your report. While leveraging auto-fill is a recommended WCAG technique and addresses ​Success Criterion 1.3.5 Identify Input Purpose, some considerations were made regarding the actual usefulness of autocomplete in the context of the various WordPress forms that relate to information about the user. We'd like to ask you for more details, when you have a chance.

Going through your points:

1
Login Form

Username/Email and Password are already provided by the browsers built-in password manager. Not sure autocomplete would help users. Also, I'd tend to think password managers are more secure. For example, they provide the ability to set a master password.

2
Lost password form

Whether users used a username or their email, looks like ​the correct value to use is autocomplete="username". Regardless, not sure it actually works with usernames. Quickly testing, I see only Chrome auto-fills using the email?

3
Password Reset Form

WordPress already fills the new password field with a suggested "strong" password. As the field is already "filled" autocomplete doesn't do anything. Seems that the autocomplete attribute would actually do something only when JavaScript is off. See screenshot attached below, where I added autocomplete="new-password" for testing purposes.

4
Add new User / Edit User

It is unlikely users would save in their browsers data of other users? How autocomplete would help when creating or editing other users?

5
Edit Profile (own profile)

This could be one of the few cases where autocomplete would be useful. Worth noting that:

- username: cannot be changed 
- nickname: it's prefilled with the username thus preventing autocomplete from working
- email:    it's prefilled with the email used during registration thus preventing autocomplete to work

Ultimately, it would work only for the following fields, unless I'm missing something:

first name: `given-name `
last name:  `family-name`
website:    `url`

6
Register form

Does this relate to wp-signup.php on multisite? Yep, maybe it would be useful for the email field. Not sure it would work for the username field.

[afercia]

autocomplete="new-password" test. From left to right: WordPress suggested password, Chrome and Firefox with JavaScript off.

[afercia]

This ticket was discussed during today's accessibility bug-scrub: agreed to close it for now, as the use case is not clear.

Worth reminding that conversation can continue on closed tickets. Also, closed tickets can always be reopened.

[rileywd]

We are getting reports from users that every time they submit the profile edit page they get an email that their password was changed. This obviously should not be happening, and is potentially alarming to the user.

It appears that some password managers incl. KeePass think the new-password fields are current-password fields and fill them. This is probably a KP bug to some extent, but is there a reason not to implement the best-practice autocomplete attributes where they're unambiguous?

@afercia:
1: Login: I'm not sure I understand - These attributes help all password managers better identify relevant fields and what to fill there.
3: Password change: In addition to the above issue, I prefer generating my own passwords, which is easier when my password manager can figure out what's going on (Neither KeePass or 1password X seem to be able to)