The WordPress core password reset needs to pre-populate the username to meet WCAG 2.2

[estelaris]

According to new WCAG 2.2 success criterion for ​3.3.7 redundant entry.

The criterion establishes that information previously entered by or provided to the user that is required to be entered again the same process is either:

• auto-populated, or
• available for the user to select

There are 3 exceptions:

• re-entering the information is essential,
• the information is required to ensure the security of the content, or
• previously entered information is no longer valid.

Once the user has performed the process of requesting a new password, the redirected form should have the username filled-in to pass. As of now, this is the form that the user is redirected to:

[joedolson]

Updating the ticket title to make it more clear what the needed change is for this.

Also removing needs design, as there's no visual change required; it just needs to populate the field, as far as I can tell.

[sabernhardt]

mentioned in an ​Equalize Digital article

[joedolson]

Note: this should also apply to the link to log-in after installation.

This PR mainly focuses upon the new feature of pre-populating the username field in the login form after password reset to meet WCAG 2.2 for accessibility.
For this feature, a new query parameter has been added to the password reset link that is sent to the email , so that after password reset the username field can be pre-field on the basis of the query parameter value user=
Screen-recording for demo

​https://github.com/WordPress/wordpress-develop/assets/96969845/ed068467-12b0-4a3a-a042-aedc45dc5f77

Trac ticket: https://core.trac.wordpress.org/ticket/60726

Contributor name - Rishav Dutta

---

[oglekler]

I assume this should cover all possible cases, when there is a need to enter:

1. Login after installation
2. Login after restoring password
3. Login after unsuccessful Login ✅
4. Restoring password after unsuccessful Login if login is correct (we are providing this information, so, there is no secret that this user exists).

For me the empty field in the last case is really annoying, because you didn't manage to enter into the admin, most likely you tried several times, and now what you want to enter should be obvious. You can make a mistake in the username, but most likely you forgot the password.

What do you think?

[joedolson]

Yes, I'd agree that those are the cases that need to be covered. I assume the green check mark indicates that the current PR already meets that case?

[rcreators]

Looks like there is still more work to do in this patch. I will create a new PR for this one to complete it this week. Else we will push it to 6.7.

[sabernhardt]

Moving the ticket to 6.7 for now.

This PR mainly focuses upon the new feature of pre-populating the username field in the login form after password reset to meet WCAG 2.2 for accessibility.
For this feature, a new query parameter has been added to the password reset link that is sent to the email , so that after password reset the username field can be pre-field on the basis of the query parameter value user=
Screen-recording for demo

​https://github.com/WordPress/wordpress-develop/assets/96969845/ed068467-12b0-4a3a-a042-aedc45dc5f77

Trac ticket: https://core.trac.wordpress.org/ticket/60726

Contributor name - Rishav Dutta

---

This PR is duplicating a number of existing parameters that are passed around containing the user's login name. Unfortunately they use a variety of names: login, log and user_login. user_email is also used during registration.

Rather than create an additional parameter user, it would be good to reuse the existing parameters.

When a user resets their password, the link they are emailed contains both their username and the reset key. These are subsequently set to a session cookie and a redirect takes place to remove the data from the URL. This is to prevent a user from bookmarking data containing their username and reset code.

I think it would be beneficial to use a similar pattern for passing around the username in the improved flow removing the need to re-enter data. As part of the registration and password reset flows the goal is to prevent users from needing to reenter their username, however I don't think it wise to allow users to create a bookmark containing their username as it could lead to issues on shared computers.

[chaion07]

Thanks @estelaris for reporting this Ticket. We reviewed this Ticket during a recent bug-scrub session. Based on the feedback received we want to note that the The changes requested are not addressed yet. We would like for the changes to be addressed and possibly revisit the Ticket before Beta is over to maintain consistency with the milestone in the Ticket.

Thank you.

Props to @pratiklondhe

Cheers!

[stoyangeorgiev]

This one was discussed at a bug-scrub and with Beta 3 in a few hours and requested changes not applied, will move this one to 6.8.

Trac ticket: https://core.trac.wordpress.org/ticket/60726

This PR prepopulate the username into the login form after the password reset using the existing query parameter.

I've tested the above patch locally, and it seems to be working as expected. The username is pre-populated when the user resets their password and navigates to the login page afterward.

Please see my note on the original PR implimenting this change, it duplicates the issues discussed there.

​https://github.com/WordPress/wordpress-develop/pull/6928#issuecomment-2276955008

[joedolson]

Not going to get this done for 6.8; moving to 6.9.

[lukasfritzedev]

I discussed this issue briefly with @joedolson on the contributor day. He suggested there is another case that should be taken into consideration: The user tries to login on one device, i.e. a desktop PC, but opens the email and completes the resetting flow on another device, i.e. a smartphone. In this case the user might want to login on the desktop PC afterwards. So I'd assume, the cases listed by @oglekler in #comment:8 should be supplemented by this case:

5. Login after requesting new password

Case 3. (Login after unsuccessful Login) was marked with a checkmark (✅). I assume this is, because it is already implemented in core.

[lukasfritzedev]

Main requirements of implementation:

• auto-populating the input user_login of the login form
• preventing a user from bookmarking data containing their username (as mentioned in #comment:16)

How to implement this:

Case 2. (Login after password reset) and case 5. (Login after requesting new password) could be implemented using a session cookie that stores just the login name (as suggested by @peterwilsoncc in #comment:16). As mentioned in #comment:8 the information that a user exists is not secret, so the username can be set as a cookie. I think there is no need for a redirect in these cases since the username is not encoded in the query parameters of the URLs at this point.

The cookie should be removed, after the login is successful. As default expiration I’d suggest 0, as it is done for the wp-resetpass-* cookie.

@joedolson suggested to use ​transients during the short discussion on contributor day. After checking the flows and considering the non-secret nature of the username, I think this is not necessary in these cases. I’m happy to reconsider this. Have I overlooked something?

I think, the same approach can be used for case 1. (Login after installation) and case 4. (Restoring password after unsuccessful Login)

[ferdoused]

The scenario mentioned in #comment:30, "The user tries to login on one device, i.e. a desktop PC, but opens the email and completes the resetting flow on another device, i.e. a smartphone" might not be relevant and can be exempt from testing because in the SC 3.3.7 success criteria it's mentioned that,

"This success criterion does not add a requirement to store information between sessions. A process is defined on the basis of an activity and is not applicable when a user returns after closing a session or navigating away."

The Understanding document (​https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry.html) explicitly says this does not add a requirement to store information between sessions. A process is defined by the activity, and the criterion is not applicable when the user returns after closing a session or navigating away. That wording covers cross-device scenarios: if you’ve finished the password reset on one device and later sign in on another device/session, SC 3.3.7 doesn’t require the site to propagate that previous entry to the other device.

[joedolson]

We didn't get this done in time for 6.9; it's too late to practically make changes to the login and authentication system. I'm marking this as early for 7.0, because I think this kind of change should really happen early.

[audrasjb]

Hello from today's 7.0 bugscrub
I support what is said in comment:35. And PR8122 appears to be a good base for a new patch.Let's keep it in the milestone until next week before punting it to Future Release.

I've updated the PR to address feedback by @westonruter and @peterwilsoncc; could use a review.

@westonruter Yes, I agree - that would greatly simplify things. It seems to me that we could also still delete the cookie; we just have to do it after recovering the value. I don't think there's any real need for that cookie to persist beyond that point to meet the requirements. What do you think?

Yes, I agree - that would greatly simplify things.

Great. I merged those commits into this branch.

It seems to me that we could also still delete the cookie; we just have to do it after recovering the value. I don't think there's any real need for that cookie to persist beyond that point to meet the requirements. What do you think?

That sounds fine to me, although I wasn't sure where that deletion should happen. Maybe here?

​https://github.com/WordPress/wordpress-develop/blob/57dbb4cee5b4c0e5d2df727338a64aa2253d5b35/src/wp-login.php#L1484-L1487

In any case, the cookie is already set to expire when the session ends, so it doesn't seem critical to explicitly delete. But I am not a cookie lawyer 😃

@joedolson I implemented this in b8b2f7206b. It seems to work. It means the cookie won't be cleared upon a visiting the resetpass login screen (the link the user clicks from the email), but rather once they click the next link to go to the login screen to use their new password.

Yeah, I'm not a cookie lawyer, either. I just play one on tv.

My only feeling about that is that if somebody previous thought it was worthwhile to delete that cookie, and we don't need to keep it longer to fix this issue, we might as well delete it.

I'm going to do a final test of this, but I think this is pretty much ready. Really happy to have been able to significantly simplify the scope of changes.

[joedolson]

The patch as marked for commit only covers the original reported case, setting the username after a password reset. There were four other cases mentioned above that could be addressed.

Two of those are cases that I don't think should be done; the other should possibly be addressed elsewhere.

The other three cases are:

1) Username field after successful installation.

This should be done, but can be addressed as a separate ticket.

2) Username field after a failed login.
3) Password field after a failed login.

I don't think there's any real value to restoring values that have already been demonstrated to be invalid. If we only restored valid values, we'd be revealing secure information in a dangerous way, but the combination of values is already definitely *not* correct. Because of this, I don't think restoring this information is useful or helpful.

[joedolson]

In 61610:

Login and Registration: Populate username after password reset.

Accessibility: to meet WCAG 2.2/3.3.7: Redundant entry, the username should be auto-populated when a user performs a password reset.

There is an existing cookie set that contains this information, but was deleted before displaying the login form.

Move cookie deletion to occur after displaying login form and use to set $user_login.

Props estelaris, alh0319, sabernhardt, oglekler, peterwilsoncc, rcreators, rishavdutta, chaion07, stoyangeorgiev, rinkalpagdar, pratiklondhe, lukasfritzedev, ferdoused, audrasjb, westonruter, joedolson.
Fixes #60726.

[joedolson]

Additional note on setting the username after an installation: it's a much lower priority fix, given how rare it is that anybody needs to manually install WordPress.