Opened 9 months ago
Last modified 8 weeks ago
#60726 accepted defect (bug)
The WordPress core password reset needs to pre-populate the username to meet WCAG 2.2
Reported by: | estelaris | Owned by: | joedolson |
---|---|---|---|
Milestone: | 6.8 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Login and Registration | Keywords: | has-patch changes-requested |
Focuses: | ui, accessibility | Cc: |
Description (last modified by )
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:
Attachments (1)
Change History (25)
This ticket was mentioned in Slack in #design by estelaris. View the logs.
9 months ago
#2
@
9 months ago
- Component changed from General to Login and Registration
- Keywords needs-patch added; needs-design removed
- Milestone changed from Awaiting Review to 6.6
- Summary changed from The WordPress core password reset doesn't comply with new WCAG 2.2 success criterion to The WordPress core password reset needs to pre-populated the username to meet WCAG 2.2
#4
@
9 months ago
- Summary changed from The WordPress core password reset needs to pre-populated the username to meet WCAG 2.2 to The WordPress core password reset needs to pre-populate the username to meet WCAG 2.2
This ticket was mentioned in PR #6332 on WordPress/wordpress-develop by rishavjeet.
8 months ago
#7
- Keywords has-patch added; needs-patch removed
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
---
#8
@
6 months ago
I assume this should cover all possible cases, when there is a need to enter:
- Login after installation
- Login after restoring password
- Login after unsuccessful Login ✅
- 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?
#9
@
6 months ago
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?
This ticket was mentioned in Slack in #accessibility by rcreators. View the logs.
6 months ago
#11
@
6 months ago
- Keywords changes-requested added
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.
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
6 months ago
This ticket was mentioned in PR #6928 on WordPress/wordpress-develop by @rishavdutta.
5 months ago
#14
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 ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
5 months ago
@peterwilsoncc commented on PR #6928:
4 months ago
#16
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.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
4 months ago
This ticket was mentioned in Slack in #core by chaion07. View the logs.
3 months ago
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
2 months ago
This ticket was mentioned in Slack in #core by chaion07. View the logs.
2 months ago
#21
@
2 months ago
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!
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.