WordPress.org

Make WordPress Core

Opened 16 months ago

Closed 13 months ago

Last modified 12 months ago

#49608 closed enhancement (maybelater)

Implementing HTML 5.2 into the user create and edit forms.

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

Description

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/EmailTBD
Passwordcurrent-password

Lost password form

Form Field Autocomplete Value
Username/EmailTBD

Password Reset Form

Form Field Autocomplete Value
New Passwortnew-password

Add new User / Edit User / Edit Profile - forms

Form Field Autocomplete Value
Usernameusername
Emailemail
First Nameadditional-name
Last Namefamily-name
Website
Passwordnew-password
Nicknamenickname

Register form

Form Field Autocomplete Value
Usernameusername
Emailemail

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 15 months 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
16 months 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
16 months ago

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

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


16 months ago

#4 @bookdude13
15 months 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 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.

#5 @derweili
15 months 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
15 months ago

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

#7 @bookdude13
15 months ago

  • Keywords needs-patch added

#8 @afercia
15 months 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:

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


13 months ago

#10 @afercia
13 months 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
12 months 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?

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

Note: See TracTickets for help on using tickets.