#49608 closed enhancement (maybelater)
Implementing HTML 5.2 into the user create and edit forms.
Reported by: |
|
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/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 |
First Name | additional-name |
Last Name | family-name |
Website | |
Password | new-password |
Nickname | nickname |
Register form
Form Field | Autocomplete Value |
---|---|
Username | username |
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)
Change History (12)
#1
@
5 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.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
5 years ago
#4
@
5 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 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
@
5 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?
#8
@
5 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:
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.
@
5 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.
5 years ago
#10
@
5 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
@
5 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?
@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)
Possibly related: #24364, #35707, #43886.