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)