form label missing in profile page

[smit08]

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.

2. Open the URL: your-site/wp-admin/profile.php

3. 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

[smit08]

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

[audrasjb]

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 :)

[smit08]

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.

[sabernhardt]

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]

removing empty fields

[sabernhardt]

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.

[sabernhardt]

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

[audrasjb]

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

[ryokuhi]

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]

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

[ryokuhi]

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

[sabernhardt]

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.

[tushar284]

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

[ashikurwp]

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

[audrasjb]

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.

[sabernhardt]

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).

[siddhantwadhwani]

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)

[pavanpatil1]

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

[mukesh27]

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

[audrasjb]

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.

[audrasjb]

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

[mukesh27]

Agreed @audrasjb 👍

[audrasjb]

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