Make WordPress Core

#56776 closed defect (bug) (fixed)

form label missing in profile page

Reported by: smit08's profile smit08 Owned by: audrasjb's profile audrasjb
Milestone: 6.3 Priority: low
Severity: normal Version:
Component: Users Keywords: has-screenshot has-patch has-testing-info commit
Focuses: accessibility, administration Cc:

Description

I was checking the accessibility of WordPress by wave chrome extension and found that the user profile page has a form label missing in the set new password field. So need to add the form label and hide it by CSS to solve it.

It was tested in WordPress version 6.0.2 and a new WordPress setup.

Steps to reproduce:

  1. Download the wave chrome extension. It is an excellent extension to test the accessibility of any site. If you have already downloaded then skip this step.
  1. Open the URL: your-site/wp-admin/profile.php
  1. Click on the wave chrome extension and it will start the testing of the page. And in the left panel, it will show all the errors.

Attaching a screenshot of the wave extension test results.

Summary view of errors: https://share.cleanshot.com/pL5TTvguCpAUJS3qUPJQ
Detail view of errors: https://share.cleanshot.com/Q0sU136fB47Q2I2euXWv

Attachments (3)

56776.patch (912 bytes) - added by smit08 19 months ago.
I have solved this issue by adding the form label field and then tested it. The error is now gone after applying the patch.
56776.1.patch (1.2 KB) - added by sabernhardt 19 months ago.
removing empty fields
56776.2.diff (1.3 KB) - added by ryokuhi 15 months ago.
Use type="hidden" for hidden inputs with no label

Download all attachments as: .zip

Change History (31)

@smit08
19 months ago

I have solved this issue by adding the form label field and then tested it. The error is now gone after applying the patch.

#1 @smit08
19 months ago

  • Keywords has-patch added; needs-patch removed

#2 @audrasjb
19 months ago

  • Keywords 2nd-opinion added

Hello @smit08, thank you for the ticket and patch,

However, I think it may be a false positive: since this input has the hidden class, it is hidden from the user agent. Then I guess we don't need a label for this hidden field. Plus, adding a label to an invisible field would probably generate another even worst accessibility issue :)

#3 @smit08
19 months ago

hi @audrasjb

First of all, thank you to review my ticket and patch. Agree with your point. I created this ticket because the wave extension was showing it as an issue. But no worries feel free to close this ticket whenever you want.

#4 @sabernhardt
19 months ago

In ticket:24364#comment:28, @sc0ttkclark asked if this input is still necessary. If we keep it, we could consider adding an aria-label in case it somehow might become un-hidden.

@sabernhardt
19 months ago

removing empty fields

#5 @sabernhardt
19 months ago

  • Component changed from Administration to Users
  • Keywords needs-testing added; has-testing-info 2nd-opinion removed
  • Summary changed from Accessibility issue of form label missing in wordpress profile.php page. to form label missing in profile page

The empty input fields were added as a hack to work around Chrome's autofill, but that could be fixed by autocomplete="new-password" (instead of "off") in r53111.

#6 @audrasjb
19 months ago

  • Milestone changed from Awaiting Review to 6.2

#7 @sabernhardt
18 months ago

Maybe we can't remove the empty inputs - see ticket:9883#comment:39

Last edited 18 months ago by sabernhardt (previous) (diff)

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


15 months ago

#9 @audrasjb
15 months ago

Yes, it looks like adding a custom value for autocomplete is our best option.

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


15 months ago

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


15 months ago

#12 @ryokuhi
15 months ago

As suggested today during the accessibility team's weekly bug scrub, a possible solution might be to add type="hidden" to the unlabelled input field, in case we can't remove it.

As defined in the HTML specification, when in the hidden-state,

The input element represents a value that is not intended to be examined or manipulated by the user.

An input with the type="hidden" attribute isn't labelable, so this would solve the issue altogether.

I'm writing a patch for this, so that it can be tested. As suggested by @sabernhardt,

The password fields already have new-password, so we would need to test in a browser that ignores it. See MDN docs

Having a look at the the autocomplete compatibility table on MDN, such a browser might be Safari.

@ryokuhi
15 months ago

Use type="hidden" for hidden inputs with no label

#13 @ryokuhi
15 months ago

Patch is ready for testing. As inputs with type="hidden" are already visually hidden, the class="hidden" can be removed.

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


15 months ago

#15 @sabernhardt
15 months ago

I think testing 56776.2.diff should involve applying 56776.1.patch first so we know that the hidden input is what prevents autofill when autocomplete="new-password" might not.

  1. Apply 56776.1.patch.
  2. Log in to your site. Save the password to your browser (password managers such as LastPass would be worth testing as well).
  3. Log out, and verify that the password autofills on the login screen. Then log in again.
  4. Go to your Profile page and click the "Set New Password" button. Note whether the password is the one you saved or a new suggestion.
  5. Add a new User. Again, note whether the password is the one you saved or new.
  6. Revert the user-new and user-edit files.
  7. Apply 56776.2.diff.
  8. Return to your Profile page and click the "Set New Password" button. Verify that the field's value is a new suggestion.
  9. Add a new User, and verify that the password field's value is a new suggestion.

#16 @tushar284
15 months ago

Test Report:

Patch tested: https://core.trac.wordpress.org/attachment/ticket/56776/56776.2.diff

Environment:

OS: macOS
Web Server: nginx
PHP: 7.4.33
WordPress: 6.2-beta1-55292-src
Browser: Chrome 109.0.5414.119
Theme: Twenty Twenty-One

Result:

✅ Before Applying the patch: https://prnt.sc/mUtApW028-zA, for Profile: https://prnt.sc/Cdommd-3dv7O and for New User: https://prnt.sc/hDQVj5l4wGok

✅ After applying the patch: https://prnt.sc/dw3_V9sKhlKR, for Profile: https://prnt.sc/JSzu7_NCqrTC and for new User: https://prnt.sc/KqU2MD7Wr01J

#17 @ashikurwp
14 months ago

Test Report:

Patch tested: https://core.trac.wordpress.org/attachment/ticket/56776/56776.2.diff

While showing error :

✅ Errors:

Profile : https://d.pr/i/eGF44Z Add New : https://d.pr/i/b02Fui

Inspection: Profile: https://d.pr/i/RdSRE6 Add New : https://d.pr/i/AXje8X

✅ After Applying the Patch Result:

Profile : https://d.pr/i/mEfFuG Add New : https://d.pr/i/co8zK2

Inspection:

Profile : https://d.pr/i/Wpq7e0 Add New : https://d.pr/i/gaVzrj

The environment in which the test takes place :

Web Server: nginx
OS: Windows 10
PHP: 8.1.9
WordPress: 6.1.1
Browser: Version 110.0.5481.96 (Official Build) (32-bit)
Theme: Twenty Twenty-Three

Last edited 14 months ago by ashikurwp (previous) (diff)

#18 @audrasjb
14 months ago

  • Keywords needs-testing removed

I also tested the patch with the following use case, on Chrome:

  • Submit from the proposed password
  • Submit after regenerating password multiple times
  • Start from an empty field and use a custom password

No autocomplete from Chrome, no bug when submitting the form.

#19 @audrasjb
14 months ago

  • Owner set to audrasjb
  • Status changed from new to accepted

#20 @sabernhardt
14 months ago

  • Keywords needs-testing added
  • Milestone changed from 6.2 to 6.3
  • Priority changed from normal to low

The patch still needs testing in Safari and/or old browsers. I do not feel comfortable committing a change this late in the release cycle (it could be considered an enhancement because it helps developers, not users).

#21 @siddhantwadhwani
13 months ago

Test Report:
Patches tested:
https://core.trac.wordpress.org/attachment/ticket/56776/56776.patch
https://core.trac.wordpress.org/attachment/ticket/56776/56776.1.patch
https://core.trac.wordpress.org/attachment/ticket/56776/56776.2.diff

While showing error :
✅ Errors -
Profile (Set New Password) : https://imgur.com/4sxnlRs

✅ After Applying the Patches Result -
Profile (Set New Password) : https://imgur.com/8Wm37nT

Steps:

  1. Navigated to the Profile page of WordPress site and using WAVE extension, was able to reproduce the Form label missing error.
  2. Applied the patches and was able to notice the Form label now present, along with hidden input field
  3. Tested across Chrome, Firefox and Edge browsers and for Safari as WAVE extension tool doesn't seem to be supported, followed steps as mentioned in comment #15 to test the flow.

Conclusion: As these cases seem to work fine for me after applying the patch and testing across browsers, I believe this ticket can be marked as fixed and closed.

The environment in which the test takes place :
Web Server: nginx 1.23.3
OS: MAC OS Ventura 13.2.1 (22D68)
PHP: 7.4.33
WordPress: 6.2-beta2-55340-src
Theme: Twenty Twenty-Three Version 1.0
Chrome: Version 111.0.5563.146 (Official Build) (x86_64)

#22 @pavanpatil1
11 months ago

Test Report:

Test report for patch - https://core.trac.wordpress.org/attachment/ticket/56776/56776.2.diff

Environment:
WordPress: v6.2.2
OS: Windows 10
Browser: Chrome

Expected Result:
Form label should be present in form.

Screenshot:
Before:
Profile Page- https://prnt.sc/t-ErGzmOGIMG
New User- https://prnt.sc/Amd9V53uUo7B

After:
New User - https://prnt.sc/gxtGTV_8YRjy
Profile Page - https://prnt.sc/27d1-erlibqi

Inspection in chrome devtool
Profile Page - https://prnt.sc/jwKJ4ROlJjtU
New User - https://prnt.sc/EqNUQ1lo7GCH

This ticket was mentioned in Slack in #core by chaion07. View the logs.


11 months ago

#24 @mukesh27
11 months ago

  • Keywords has-testing-info added; needs-testing removed

This ticket was discussed in the recent bug scrub.

The test report indicates that the patch is working fine. Now, we need @audrasjb to review and provide feedback.

Additional props to @chaion07

#25 @audrasjb
11 months ago

  • Keywords commit added

I gave it another try and everything looks good to me. With almost a dozen successful tests, let's commit this asap in the release cycle.

#26 @audrasjb
11 months ago

To clarify: 56776.2.diff is the patch I tested and I marked for commit consideration.

#27 @mukesh27
11 months ago

Agreed @audrasjb 👍

#28 @audrasjb
11 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 55892:

Users: Use type="hidden" for hidden input on User edit administration panel.

This hidden field added in [24552] to fix an issue with Chrome that was ignoring autocomplete="off" in <input>, by using a hidden, non-named, non-empty
input right before the password field. However this input was only hidden via CSS and didn't have any label, which is considered as an accessibility issue.
This changeset replaces class="hidden" with type="hidden" to properly indicate to user agents that it is an hidden field.

Follow-up to [24552].

Props smit08, audrasjb, sabernhardt, ryokuhi, tushar284, ashikurwp, siddhantwadhwani, pavanpatil1.
Fixes #56776.

--Cette ligne, et les suivantes

ci-dessous, seront ignorées--

M trunk/src/wp-admin/user-edit.php
M trunk/src/wp-admin/user-new.php

Note: See TracTickets for help on using tickets.