Replace confirm password element with a new password element with show/hide functionality

Updated patch for 9.5.x

Re-upload

Fixed build errors, Attached interdiff for same. please review

Seems patch #210 failed to apply.

This was previously tagged for issue summary update which from what I can tell still needs to happen please.

Thanks.

During yesterdays usability meeting 📌 Drupal Usability Meeting 2023-09-01 Needs work we've discussed 🐛 Password suggestions are hidden from screenreaders Active and the whole password creation and altering process in the Drupal installer and on the user profile page in general. This issue was touched during the discussion. There was a clear consensus in the group that from a usability standpoint it would be a more than welcome and important issue to fix.

I am adding the Needs reroll tag as recommended in the meeting by @benjifisher and @lauriii . #201 📌 Replace confirm password field with show/hide functionality Needs work "might" be a good place to start the reroll @lauriii presumes. All patches after that failed tests as well and as noted in #204 📌 Replace confirm password field with show/hide functionality Needs work even though the patch in #203 📌 Replace confirm password field with show/hide functionality Needs work applied none of the actual functionality was available in the interface so maybe that is not a good place to start.

And for the record 📌 Drupal Usability Meeting 2023-09-01 Needs work will have a link to the recording of the meeting. The attendees at the meeting were @aaronmchale, @benjifisher, @emma-horrell, @lauriii, @rkoller, and @worldlinemine.

And for reference the following comment might be of use for this issue as well: #3272325-6: Password suggestions are hidden from screenreaders → . I've compared the password field behavior there between Drupal, WordPress, Typo3, Joomla!, and CraftCMS including short videos for each of the systems illustrating the usage with MacOS VoiceOver. All of them have a hide and show functionality for the password but with differing behaviors implementation wise. Maybe the videos are of any use for this issue as well.

I have created a patch for 11.x, please review

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Thanks for working on the reroll @gauravvv

I've successfully applied the patch in #215 📌 Replace confirm password field with show/hide functionality Needs work to a Drupal 11.x-dev install. The hide and show functionality is working in the latest version of Microsoft Edge on MacOS 12.6.8 while the hide and show icon and functionality is not available for Safari 16.6 and the latest Firefox. I will test it functionally with VoiceOver later today in Edge for now. And a few tests are also failing. I'll set the status back to Needs work.

A few details I've noticed when testing in the latest stable version of Microsoft Edge and VoiceOver on MacOS Monterey (12.6.8):

1. As soon as a field that is showing and unhiding a password looses focus (for example you open devtools, you click outside of the field or window) the password is hidden again. Problem is the hide/show icon completely disappears. You have to clear the password field and start to reenter something that the icon is showing up again.

2. When the password field looses focus there is no announcement in the screenreader that the state of the password changes back to hidden. That way as a screenreader user I would expect that the password is still visible in the state I have set before?

3. Is the "confirm password" field necessary at all with the ability to hide and show the password? That way one is able to check and or copy and paste the visible password? Other CMSes also have dropped the confirm password field with a hide/show password functionality in place - see #3272325-6: Password suggestions are hidden from screenreaders →

4. In Edge the Icon is not accessible by the keyboard. After entering a string into the password field and the hide/show icon was showing up I was unable to reach the hide/show icon by keyboard. I've tried to tab (for the "current password" field the "reset your password" link gets into focus for the "password" the "confirm password" gets into focus on tab) and to use VO and arrow keys. In both cases I was unable to reach the hide/show icon.

5. In combination with the announcement text " you are currently on a text field. to enter a text in this field type. this is a secure text field. text typed into this field will not be displayed and will not be spoken by VoiceOver." the option to hide/show passwords is invisible and not directly apparent to the screenreader user (#195 see also https://www.drupal.org/project/drupal/issues/2293803#comment-13968132 📌 Replace confirm password field with show/hide functionality Needs work ).

6. If I manually click the hide/show icon and set the password to visible that change isn't announced by VoiceOver instead I again get the same announcement like when the password is hidden "you are currently on a text field. to enter a text in this field type. this is a secure text field. text typed into this field will not be displayed and will not be spoken by VoiceOver."

6. Unfortunately the functionality isn't showing up in Safari. But I suspect there might be some overlap and interference between the Safari password widget and the hide/show password icon.

Both inline inside the password field already leads to issues for Typo3

and it might be difficult to accomplish some sort of coexistence and clean layout for both.

one potential idea so solve 4 and avoid in particular 6 might be to add an hide/show button right after the password field with the icon and a label text instead of just the inline icon within the password field. that way things would be more explicit and clear - a pattern wordpress applies:

that might cover also the point brought up in #195 📌 Replace confirm password field with show/hide functionality Needs work that just hide and show as label might be too vague for screenreader users.

for sighted users having an icon with a label based on the state (hidden or shown) would make things clear; having just an icon might make some users think about its meaning. and for screenreader users having an a bit more verbose aria label with something like "make password visible" and the switch state would be clearer as well (the exact wording would have to be discussed). and @andremacpherson also suggested to make the user aware if the toggle comes after the text box.

Fixed the CCF issues, Need to addressed #218, So Keep as in 'Needs work'.

Fixed the fail test case. Please have a look.

Now the show password is properly spaced.Attaching the screenshot.

Left some comments, also looks like this still needs an issue summary update.

Trying to clean up the tags some. Don't see much use that this ticket was worked on at an event in 2016 :) feel free to add any back.

Hate to do it but was previous tagged for issue summary and don't believe that has happened.

The MR now has the password_type_reveal config set to true for the existing as well as new users so as to keep it consistent. The users can disable it if they want from the account settings.

I had a discussion with @lauriii and @tim.plunkett and we decided to deprecate the password_confirm and remove the user configurability of the new password show/hide functionality.

Drupal\Core\Installer\Form\SiteConfigureForm also needs updating to switch to the new element.

Some additional aspects not mentioned yet. I've tested the lasted state of MR4780

I think the width of the password strength indicator should have the same width as the password field like without the patch applied. Because with the patch applied the strength indicator width follows the viewport width instead of the fields's width as shown in # 223 📌 Replace confirm password field with show/hide functionality Needs work . For wide screen monitor >30" it becomes an even more visually challenging task to check the actual current strength and then jump back and forth to the password field.

Would it make sense to add the hide and show functionality for the current password field as well on the user profile page? what applies to the new password field applies to the current password field as well. If i want to see the entered new password i would also like to be able to see the current password entered.

And was it an intentional step to remove the password suggestions box? The box isn't shown anymore after the first character is entered like before.

thanks for the changes @utkarsh_33! i've applied the latest changes and i can confirm that the password suggestions ( #230.3 📌 Replace confirm password field with show/hide functionality Needs work ) are back in and that the show and hide password functionality is also available for the current password ( #230.2 📌 Replace confirm password field with show/hide functionality Needs work ) now. neat thank you!

1. But by making the password suggestions available again the width of the suggestion box is now the same as the width of the strength indicator. that way that block gets even more visual weight for widescreen displays in particular.

i still vote for the behavior that was in place before the patch, that the width of the strength indicator and the suggestion box is the same as the width of the width of the password field.

2. Another detail i've noticed when testing the functionality on microsoft edge i've noticed that chrome based browsers provide such a functionality out of the box as an inline icon:

would it be possible to hide that icon chrome based browser provide somehow? cuz having two options alongside is sort of redundant and confusing to the users. plus the icon disappears as soon as the field looses focus and isn't reappearing if the field regains focus.

3. one detail that was first raised in #195 📌 Replace confirm password field with show/hide functionality Needs work is the question how the state of the field (if hidden or shown) is announced to a screenreader user. i've added a jump mark to the link to leonie watsons talk on youtube: https://youtu.be/OUDV1gqs9GA?t=3219 . there she illustrates well the problem if the aria-pressed attribute is used in combination with having a button label for the different states. in the current state of the patch the announcement for the toggle button in voiceover in safari is:

show password, toggle button
hide password, selected, toggle button

for hide password it would make me at least think. if the dynamic button labels should be kept the suggestion in #195 was to use the role="switch" attribute instead of the aria-pressed attribute.
the other option might be to keep the aria-pressed attribute but use a consistent label of either show password, reveal password, or View password. View password might tackle the worries @andrewmacpherson in #195 📌 Replace confirm password field with show/hide functionality Needs work raised in regards of the clarity of the button label as well. for screenreader users that would be the clearest approach imho.
for sighted users instead is having the same button label for both stats not that clear. two suggestions in that regard. in general would it make sense to move from a plain text link styling to a button styling? Then one option might be to have the label View password and when aria-pressed is set to true have a pressed button styling that signifies the function is active. the downside i am not sure if a styling for a pressed toggle button already exists in the drupal design system?
the other option might be to make the button label visually hidden and add an icon for the visible state (an eye icon for example) and an icon for hidden state (a striked through eye icon) and dont announce those icons by the screenreader?

4. another point mentioned in #195 📌 Replace confirm password field with show/hide functionality Needs work about "The toggle comes after the text box, which can cause confusion in a couple of way" would still need an agreement on a solution. the suggested approach there is to go with an accessible description mentioning the nearby switch.

I definitely prefer the show/hide feature to be outside the input field. That example with the Light/Dark mode that you pointed to in the Youtube video would work well. Would allow us to have the button as a button too. Probably we'd want to swap the text or image to let folks know that their password is now visible (or invisible).

When tested manually, found some issues. Please see attached screenshot:

• Password strength indicator is showing below current password field + 232.1
• Show/hide password is visible as button with missing css, may be
• Confirm password is still showing up on site install.

I have assigned the show password button and Aria role=switch as mentioned in #195 📌 Replace confirm password field with show/hide functionality Needs work along with the updated message requested.

I have added the ability to add the strength bar optionally as you can see the screenshots addressing Comment#234.2.

Seems to have a test failure

Also could someone familiar with the issue take a look at the issue summary. Was tagged a long time ago but scanning the page don't know if it was updated.

• The toggle uses a <button> tag, as it should. However, it is styled like a link - there should be a means of visually distinguishing the button (which triggers functionality) from a link (which takes the user to a new destination). This should be happening regardless, but it's particularly a concern here since the looks-like-a-link toggle is quite close to an actually-a-link element that is styled the same
• This has been mentioned in other comments, but I notice the password input in the login form does not have this password-show functionality. It seems like a good idea to include that here - even if it were planned for later that would be the most effective way to confirm the implementation can support this use. If there's a solid reason for not including it within this issue's scope, that should be included in the issue summary (it is possible I missed an explanation in the many comments above)
• The final item in #195 (The toggle comes after the text box...) is probably worth addressing, even if I haven't seen it addressed in other accessible password widgets. Any measures that can be taken to avoid unknowingly visually revealing a password should probably happen. At the risk of having a
  different take from the more-thorough #195, I'd prefer this information to be visually hidden as the hide/show state should already be reasonably apparent to sighted users via the buttons, and the password fields are already a bit visually noisy as-is. The #description approach might but would need to preserve any existing description. Another possibility is using aria-description and appending any text from the description element.
• It seems like there may need to be some additional styling to remove the MS Edge provided hide/show controls. My usually-reliable Virtualbox that lets me use Windows 11 is not cooperating, so I'll either need to get that addressed or better yet someone with an already-available Windows environment could check that out.
• The change record needs more detail. It's currently showing before after screenshots of the profile form and says "Previously the users were asked to re-enter the password in the confirm password field and if the user enters the password it cannot be viewed in both the password field. So with this MR we want to deprecate the confirm password field and add a button next to the password field which will enable the user to see the password." Lets update it to remove mentioning "MR" (once merged it's no longer an MR 😉), describe the new render elements, and provide code examples of how they are used compared to their predecessors. One of the best ways to get a sense of what goes into a good change record, is to go through the list of existing change records → and see how they are written.

I have addressed the feedbacks in #240 📌 Replace confirm password field with show/hide functionality Needs work related to link should look like a button and also included the show/hide functionality in the login form.
Attaching the screenshots to get feedbacks if any from design perspective for the latest change
.
Also regarding the comment related to #195 📌 Replace confirm password field with show/hide functionality Needs work related to (The toggle comes after the text box...) i think I'm not a 100% sure about this change.So maybe some further help is required on that point.

Regarding #240 there is widespread patterns of having the "show password" styled as a link. For instance USWDS
https://designsystem.digital.gov/templates/authentication-pages/sign-in - that should be accessible.
But I do see the problem with having an actual link close by...

Also regarding the comment related to #195 related to (The toggle comes after the text box...) i think I'm not a 100% sure about this change.So maybe some further help is required on that point.

If a user navigates to the password field via a screenreader, and that password field is currently set to type="text", thus making the password field visible. They are not aware of this fact until after they've entered a password and navigated forward to the hide/show button. Ideally, when the password is fully visible, an AT user should be aware of this as soon as they land on the password field.

AFAIK If the user navigates to the password field via a screenreader the password field is set to type="password" by default unless you toggle it's type to text after pressing the show password button.
Attaching the screenshots for respective states.
Initial state:

State after clicking the show password button:

I totally understand the different points made for this element to look more like a button, and different from a link. But on a design perspective using a regular button is not good enough: apart from it being an unusual pattern, it takes too much visual attention to it and the expectations from users after clicking a button might not be what we expect.
All the accessibility feedback needs to be addressed but we can't penalize sighted users this way. Luckily, this discussion has already happened with other UI elements and we reached an agreement for an element: the Action link, used in the "Show/hide row weights".
So my recommendation here would be using the component Action link, on its small variation. It would look like this:

(Obviously the icon would switch with the text too as it's already happening with the "Show/hide row weights".)

Thanks for the clarity @ckrina. I have updated the element as requested.Attaching the Screenshots for both the states.
Show password state:

Hide password:

I have also updated the CR.

Nice work, Updated CR, most changes are related to tests which seem reasonable, just some nits with JS parts.

With all this feedback still believe issue summary should be updated to latest. Or least documented why it's no longer needed

Tried to test with the MacOs Voice over functionality but it doesn't announce the aria-description could be related to https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Annotati....

The following are comments based on the a11y maintainers' discussion during the office hours today (and not a recommendation for moving this forward -- we are putting them here for reference). A maintainer will follow up with an actual recommendation shortly.

--------------

When providing a toggle switch, it is useful to focus the label on the function which is changing rather than changing the whole text. We aware that needs of screen reader users may be at odds with the needs of people with cognitive disabilities.

In order to prevent confusion for both an individual using a screen reader (changing the label of a toggle element), and an individual with a cognitive disability that can make it difficult to generalize concepts and need things to be direct and explicit.

In this case, a label of "password visibility" would focus on the function of the toggle instead of the state, which can avoid this conflicting confusion.

A screen reader user will also have an affordance through the screen reader indicating the current state, so the same would need to be present for a sighted user. Example: an icon that changes its qualities to convey the current state to the user. It should not be assumed that the actually presence of a visible password is sufficient to convey the current state to a sighted user.

Currently, visibility can only be toggled by counter device, so it is not possible to test screenreader/AT implementation.
I left feedback in the MR regarding how to address this, and once that is completed I can potentially provide accessibility signoff.

kunal.sachdev → made their first commit to this issue’s fork.

Hey folks, been around for a while and trying to follow the transition from patches to MRs but as I'm on Drupal 10.2 I have absolutely no idea which patch or MR I should be using for this. Can anyone advise?

@brooke_heaton, you can use this https://git.drupalcode.org/project/drupal/-/merge_requests/4780 MR.

tim.plunkett → changed the visibility of the branch 2293803-replace-confirm-password to hidden.

Addressed all the feedback. Also there is an unrelated CSpell failure in MR fatal: bad object c574a6e4f0867d27a49a244ee9648d7adfaf9f9b.

Going to work on resolving the test failures.

The performance test is failing because this is introducing an additional cache query in core/modules/user/user.module::user_form_process_password_unmask(). I think we can increase the query counts by one to resolve the test failure.

I took a look with this issue with VoiceOver, and with keyboard-only reviews. This looks good. Like the new pattern with the show/hide text.

I've noticed one detail when I tried to log into the site with the latest changes from this MR applied. The login screen is also showing me the password strength indicator as soon as i start to enter a password there.

There's been some discussion in Slack to move the password strength indicator before the input form so that a user is told how they should comply before fill in the form. I thought that the password strength indicator was semantically linked to the password field by aria-describedby but can't seem to find that now.

I suspect with these changes we should put on "Needs Accessibility Review" and "Needs Usability Review" but I wonder if we can't commit this and create two smaller follow-up issues.

This one is already approaching its 10th anniversary.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Rebased with latest changes by resolving conflicts.

There is one detail to note about the micro copy used for the aria-label that is based on the suggestion made in #195 📌 Replace confirm password field with show/hide functionality Needs work ) . When tested in VoiceOver you get the following announcements:

make password visible, on switch
make password visible, off, switch

The problem is the following, the cognitive load is rather high for figuring out what the actual current state is and what the future state will be when clicking the button. make password visible, on switch describes an action to take, to make the password visible, with the switch set to on - but the state the password field is in is hidden. While with make password visible, off switch the password is actually shown. Based on the aria-label I would expect that state of the password field the exact opposite way around than it actually is.

I've discussed the topic with @mgifford in this thread on Slack as well as @Emma Horrell today. There was a consensus in both discussions that the current label is hard to comprehend in context, even though the reasoning behind was valid in the first place.

In both discussions we've tried to ideate and come up with alternatives. Instead of using a task like "make ..." use a term that describes the state or function of the button was the goal. Something like Password camouflage would describe things well but it is a way too abstract term. Other ideas were Password cloak (the term cloak is usually used in a slight different context not to hide but to encrypt), Password mask (the term mask is probably too ambiguous, unclear and context sensitive), and Password hidden. In the end we tried to simply invert the term visible and remove the verb make which brought us to:

Password invisible, on, switch => password hidden
Password invisible, off, switch => password shown

Still not perfect but it would be at least more clear. We also tried to explore what other sites and CMSes use, but most or better all of them in case they have the hide and show functionality use the same switching labels sighted users see (checked a few: WordPress, Joomla, GitHub, GitLab, Twitch, Amazon, the MoJ Design System from gov.uk). Further options could be to do some wordsmithing for the aria-label at the next usability meeting and/or to run a one-two punch content test with users.

I guess the show password isn't that important on the login page so just removed it with the strength indicator.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Updated for login show password.

The changes looks good.

Added some questions to the MR.

Also this feels like a fairly late and possibly disruptive change, should we consider keeping the old element around until Drupal 12 as per 🌱 Defer disruptive 10.3 deprecations for removal until 12.0 Active ?

sorry for the late reply @omkra.podey but i had to wait before i got word from the others who ideated on the aria-label suggestions with me. i've now manually tested the patch again another time:

It is a good choice that you've readded the hide and show password button in #277 📌 Replace confirm password field with show/hide functionality Needs work . It is definitely useful for the login page in the front end. the only nitpick i've noticed in claro there is the eye icon, that icon is missing in olivero in the front end. but this minor styling issue might moved to a followup issue?

in regards of the aria-label Password invisible it is definitely an improvement over make password visible making the label more clear. I still had some doubt after actually testing it with voiceover because Password invisible from a grammatical perspective sounded slightly off and something like Password invisibility, on would feel more grammatically correct as @Emma Horrell put it. But the term invisibility has the downside that it is too complex and invisible conveys the meaning adequately. So the arial-label seems good to go. And there is always the option to simply change the string of the aria-label at a later point based on user feedback and running some user test like for example a one two punch user test. But that could be done in a follow up issue if necessary and shouldn't hold back this issue.

this issue looks good overall

There is one remaining unanswered thread in the MR https://git.drupalcode.org/project/drupal/-/merge_requests/4780#note_280791.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

I believe all threads have been answered, though can't close any. But MR needs manual rebase

Mithun S → made their first commit to this issue’s fork.

Pushed a rebase from the 11.x branch. Please review

Seems rebased added some failures.

pooja_sharma → changed the visibility of the branch 2293803-Replace-confirm-pass to hidden.

pooja_sharma → changed the visibility of the branch 2293803-Replace-confirm-pass to active.

After rebased MR, fixed test failures of pipeline(II stage)

However, there are still some test failures of pipeline(III stage) that's needs to be addressed.