Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#49608 closed enhancement (maybelater)

Implementing HTML 5.2 into the user create and edit forms.

Reported by: derweili's profile derweili Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Users Keywords: reporter-feedback
Focuses: ui, accessibility Cc:


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

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


Login Form

Form Field Autocomplete Value

Lost password form

Form Field Autocomplete Value

Password Reset Form

Form Field Autocomplete Value
New Passwortnew-password

Add new User / Edit User / Edit Profile - forms

Form Field Autocomplete Value
First Nameadditional-name
Last Namefamily-name

Register form

Form Field Autocomplete Value

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.

Attachments (1)

49608 autocomplete test.png (249.4 KB) - added by afercia 4 years ago.
autocomplete="new-password" test. From left to right: WordPress suggested password, Chrome and Firefox with JavaScript off.

Download all attachments as: .zip

Change History (12)

#1 @SergeyBiryukov
4 years ago

  • Component changed from General to Users
  • Focuses ui added
  • Summary changed from Implementing HTML 5.2 into the use create and edit forms. to Implementing HTML 5.2 into the user create and edit forms.

#2 @SergeyBiryukov
4 years ago

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

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

4 years ago

#4 @bookdude13
4 years ago

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 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.

#5 @derweili
4 years ago

@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?

#6 @bookdude13
4 years ago

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

#7 @bookdude13
4 years ago

  • Keywords needs-patch added

#8 @afercia
4 years ago

  • Keywords reporter-feedback added; 2nd-opinion needs-patch removed

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:

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.

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?

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.

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?

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`

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.

4 years ago

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

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

4 years ago

#10 @afercia
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed
  • Version 5.4 deleted

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.

#11 @rileywd
4 years ago

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?

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)

Note: See TracTickets for help on using tickets.