Password suggestions are hidden from screenreaders

We talked about the issue in todays a11y office hour (18.08.2022 -link to the notes).

Aside the issues described in the issue summary there was also noted that in case the user is zoomed in the password recommendation box might be missed. also people with visual disabilities and or problems with visual processing as well as the working memory might have problems with the functionality. remember the entered password for the confirmation dialogue, visually process the recommendations box which comes off as a wall of text with tiny typography and so forth. one link provided in regards of best practices was the following: https://www.nngroup.com/articles/password-creation/. for more details consult the linked meeting notes please.

We then agreed for illustration purposes to upload a screen recording to demonstrate the problems in Drupal on a Mac with voiceover. I've then extended the exercise to a few more CMSes to get an idea what others do well and where they also lack. Some of the videos are for already installed sites some were taken during the initial installation process. Disclaimer not all videos are perfect, using voiceover while performing a screen recording leads sometimes to odd browser behavior as well as reaction - there for apologies for the occasional hick ups.

- negative aspect
+ positive aspect
+/- mixed with positive as well as negative aspects

Drupal - installer
- the field for the new password is just called password instead of referring to the action. It could be Choose password or Select password

+/- the password strength is announced. but may be the wording could be front loaded. at the moment it is password strength strong. front loaded it would become strong password strength. that way the screenreader user is able to aurally scan because the information of interest is the strength level and not the label of the level. and on a side note as you can hear with password strength fair, fair gets blended out and the volume is lowered - hard to understand but not sure what is causing that output?

- there is no way to show the typed in password. for people with a small working memory that could turn into a problem to remember. to enter the password a second time from memory into the confirmation field could become a challenge. and there is also the general question of the reentering of the password for confirmation is necessary at all if it is possible to hide and show it. there is already an issue: https://www.drupal.org/project/drupal/issues/2293803

- the recommendations aren't announced and stay completely unnoticed (as already stated in the issue summary). plus why show the rules for the to be entered password after the first character is entered. at that point the user already made up their mind what password to enter in case they manually enter. now the sighted users have to stop compare from the top of their head the password they want to enter with the rules laid out. for screen reader users it would be even more challenging even if the recommendations are announced. they have to listen to the list of rules, memorize them and then check against their password choice - all from the top of their head.

Drupal - user profile
- the current password has to be entered at the beginning. three more fields down the DOM there is the password field. the two fields are spatially separated. if you know from the start that you are gonna change the password or email address then it is fine but if you wanna change it at a later point or if you even forget about that you have to enter the current password then the flow becomes inconvenient. that issue was already identified in one of the child issues of the following issue in the ideas queue: https://www.drupal.org/project/ideas/issues/3251513 (the issue is about user edit pages)

- the field for the new password is just called password instead of referring to the action Enter new password like it is named for the confirmation with confirm password which could be also be changed to Confirm new password.

* the rest of the points are identical with the drupal installer.

WordPress - installer
+ wordpress is autopopulating the password field with an randomly generated password string. the generated password is shown and not hidden per default. that way there is no real need to add a password recommendations text and the autogenerated string is used as illustrative material

- the announcing of the password strength as well as the input in general is overeager and gets announced too fast if there isn't any keyboard input

- the state of the show/hide button isn't announced
Update:
+ the state of the show/hide button is actually announced correctly. i've used the space and return key to interact with for example buttons but to have everything announced properly you have to use ctrl-option-space instead if used with voiceover i've learned. that way the state change is announced correctly. the focus remains on the hide and show button. to get the content of the field announced after you've made it visible by clicking the show button you have to shift tab once.

WordPress - user profile
+ the action Set New Password is a dedicated button with a label New password.

- after the set new password button is clicked the button is still visible. it isn't apparent that it could be used to re generate a new password again and again.

+/- i've created an additional wordpress_confirm_weak_password.mp4 recording. having a checkbox that appears to confirm that you are aware using a weak password i consider a good and useful practise from a security perspective, or at least a good compromise for local test installations. but the checkbox isn't getting announced and is placed after the cancel button. if someone directly saves the page after entering a new password, in case that was the only objective, then an error will turn up on the form.

Joomla
+ the sole password rule/requirement is clearly stated for everyone (sighted as well as screen reader users) with enter at least 12 characters

+/- password doesnt meet the sites requirements is announced after the first keystroke which is good. after that no state change is announced if the meter is going from red to yellow or yellow to green. the announcement password accepted is misleading.

+ the state of the button is announced aka the action and effect pressing the button.
Update: when the button is clicked the focus is automatically shifting back to the password field. in case you clicked the show button the password is getting automatically announced to you.

- my biggest gripe with the joomla installer. it looks you are on dedicated installer pages. you go through page one to four. two of the pages contain the action of choosing and entering a password. if one hasnt met the criteria you get an error at the end of page four and it turns out it is a single page overall and it is difficult based on the error messages even for a sighted user to know where the error was and in particular where to fix it cuz now all pages are shown at once.

Typo3
- the announcement of the recommendations showing up when the first character is entered into the password field gets immediately stopped on the second keystroke. if you enter a password manually you usually add the first one or two characters fast that way the announcement gets cut off. problem if you leave the field and reenter that announcement isn't made again. seems it is only announced when it showed up for the first time.

- the change of color code based on the password strength isn't announced to the screen reader.

- that there is a show and hide functionality isnt apparent. you have the lock icon which, me personally, i dont associate with a hide and show functionality. the icon also gets overlayed in part by the key icon from macos safari.

- the state change if the password is hidden or shown with the icon/button isn't announced.

CraftCMS - installer
+ it is using the text show and hide instead of an icon. that way it is crystal clear what the state and actions are (also for sighted users). and works well with the browser password icon.

Update:
+ the focus is switching from the show/hide button to the password field when clicked so the password gets properly announced directly. in contrast to the others clicking and announcing also works with space or return, ctrl-option-space isn't necessary.

- no feedback in regards of password requirements - and you are basically allowed to enter anything as short or long as you want. Update: it seems the password i've tested with had six characters which is the minimum character count as seen in the update for the craft cms user profile

CraftCMS - user profile
- you enter the new password but are unable to reach the save button by tabbing from the new password field on. had to use the mouse.

- the confirmation dialogue enter your password to continue is super unclear what password to enter there. the old password or the new password to confirm it? as you can see at the end it was the old password. pretty confusing and unclear ux copy wise.
Update:
- there are no requirements listed for the new password nor a strength indicator but after saving the new password i get the error New Password should contain at least 6 characters.

Possible steps for the Drupal implementation (i use a numbered list for easier reference)

1. for the installer the authentication that the user is allowed to make the changes should be changed. that way the spatial separation wouldnt't be necessary anymore like it currently is. there exists already an issue in one of the issues listed in the aforementioned issue in the ideas queue: https://www.drupal.org/project/ideas/issues/3251513
2. the confirm password field should be dropped and a show and hide functionality introduced (see https://www.drupal.org/project/drupal/issues/2293803 - but that would not only apply to the installer and the user profile page but also to the login dialogue to a drupal site). having only a single field would also solve the problem for zoomed in users that they might miss information because two password fields with descriptions and the recommendation box take a lot of vertical space.
3. for the hide and show functionality it might be worth a thought use hide and show instead of an icon? or an eye and striked through eye icon along with a label show and hide
4. based on a link @mgifford shared after the meeting on slack it might be worth a thought to rethink the password recommendations box: https://www.npmjs.com/package/nordburg-pw-reqs . question is it necessary at all? and as it was stated in the meeting notes the box is a wall of text. then it introduces another level of complexity because it is updated if one of the listed criteria is satisfied. also those requirements currently only showing up after the confirm password field. would it make sense to make the requirements compact, front load them before the password field, and show them to everyone. keeping that information static and tie it to the password field with: aria-describedby. then the password strength would remain the only dynamic announcement to make
5. having a dedicated button like wordpress for changing the password and open up a modal or new page or make it inline like wordpress would be an idea as well as auto generating a password and filling the field with a suggested value. moving the password change was also discussed in the issue in the ideas queue
6. another idea instead of dealing with recommendations it might be also an idea to consider trying to adopt passkeys coming to apple, google and microsoft soon: https://twitter.com/rmondello/status/1555264040644972546 and https://twitter.com/rmondello/status/1533962232798728192 . which might fix many of the problems out of the box.
7. and the micro copy of the labels should be rethought as well based on which choices were made for the points before

We have discussed the issue at #3383430: Drupal Usability Meeting 2023-09-01. The issue will have a link to the recording of the meeting. For the record, the attendees at the meeting were @aaronmchale, @benjifisher, @emma-horrell, @lauriii, @rkoller, and @worldlinemine.

There was a clear consensus that this is relevant issue to fix. It was noted that in the future, with the introduction with additional authentication methods like single sign on, passkeys by the Fido Alliance, or mailed one time login links. But as long as Drupal provides the option to login with a username and password the password suggestions should be accessible to screenreader users as well.

The usability grouped signed off on the proposed resolution based on the linked article so work could take place to implement the solution.

I'll remove the Needs usability review for now but am following this issue anyway and I can bring in the issue to a future meeting again. I've also updated the issue summary because the page for the linked article is down due to a database issue so i've added a link to archive.org.

At first thank you for the initial MR and apologies about the late reply - i had too many things in parallel the last few weeks. So far the issue was only discussed at the weekly ux meeting, therefore I've raised it at the last a11y office hour on the 2024-04-18 (for the record the attendees were @bnjmnm, @mgifford @psebborn @rkoller, @Sanna Kramsi (no username on d.o), @shaal, and @the_g_bomb).

The conclusion was two fold. First it looks like there is a regression in https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/user/... according to @bnjmnm. Both @bnjmnm and @mgifford were under the impression that the announcement of the suggestion was working in previous versions of Drupal. The agreed upon approach was opening up an additional issue to fix the announcement of the suggestions in the short term as a quick improvement (see #3444209: [Regression] Password recommendations are not being announced to screenreader users and to use this issue for coming up with a more future proof better approach.
In general the idea of informing the user upfront about the password requirements was considered a good thing (for sighted as well as screenreader users) but there was also the worry that there might be an information overload and with the password recommendation and password strength announcement working, things might become a little bit too verbose and overwhelming. We've taken a look at the current implementation of the patch on Safari 17.4.1 on macOS 14.4.1 with VoiceOver. Problem was that the initial entire set of recommendations wasn't announced still.

see https://www.drupal.org/files/issues/2024-04-29/recommendations.mp4 (for context at the beginning i've stepped through every available element with the voiceover cursor by tabbing "VO-arrow right" to make sure i am not missing some visual hidden instructions instead of stepping through by just using the tab key)

One suspicion the group had was that the reason why no announcement of all the recommendations takes place is that there might be a conflict with other content sent to the screenreader and that there is some sort of "race condition". One additional suggestion was to maybe go with aria-describedby. But I agree with the reasoning in #11 that aria-details might be the more appropriate pick semantically. but i did some digging yesterday and it turns out that the support for aria-details in particular for voiceover might be potentially problematic according to https://a11ysupport.io - maybe another explanation why the initial list of recommendations is not being announced?

Taking a look at the current output you have the announcement of only one of the recommendations several times, the rest is going unnoticed, at the same time you have the announcement of the password strength alongside, plus at one point the announcement of that "bullet bullet". But that brings us back to the already mentioned information overload. With everything properly being announced a person would have to process the entire list of recommendations, then there will be a ping pong in between the strength indicator announcements and password recommendation announcements. One idea that was initially voiced during the meeting was to provide some sort of wizard for the aural interface - that way it would be ensured that only directly actionable information is provided to the user. But we haven't had enough time left on that day and agreed on continuing the discussion on this issue.

While writing up this comment i gave the problem some further thought and came up with the following suggestions:

1. Having password recommendations AND a password strength indicator is overwhelming, plus as soon as you've satisfied all requirements you have a strong password. So removing the strength indicator might be a reasonable first step?
2. Make a screenreader user aware of the list of password requirements is a good thing. but with a short working memory it becomes challenging and the call to actions in regards of password requirements you have anyway. based on the aural interface wizard suggestion, the order of the default requirements (add uppercase letters, add numbers, add punctuation) could be randomized. So before the first character is entered with the password field in focus the user would get as the call to action for example "add upper case letter" and then after satisfying that one the person gets the next. as soon as all three requirements announced in random order are satisfied one could get the at least 12 characters requirement as the final one. and when all requirements are met there could be an announcement, something like "your password is strong, you are meeting the requirements". the advantage, if someone copy and pastes the password from a text file or password manager, one would either get the requirements left to satisfy the outstanding requirements or directly end up with the "your password is strong..." announcement.
3. One thought that came up in a follow up discussion with @mgifford, is the case when the password is not meeting the password requirements. At the moment it is possible to save a user account with the password 123 or a. The ideas were to either notify the user via an announcement while saving the user account (problem there, it could go unnoticed), add a confirmation step on save making the user aware that the chosen password is not strong enough satisfying the requirements, or go with a pattern wordpress uses by adding a checkbox on the user edit form making the user to confirm that one is aware and fine with using a not that strong password.

at first apologies, i somehow missed your last comment mid june. :( but i have taken a quick look at the current state now. at first happy to hear that with this approach a lot of hard coded things would be dropped. that sounds like a good thing, awesome!

in general, personally i like that the recommendations are shown now all the time next to the field for updating the password field instead of showing them right after the first keystroke. that is setting the context better for sighted users.

in regards of the experience for screenreader users i've created two small videos. in the first run through (full.mp4) all the recommendations are announced which was "sort of" an exception, during most of my tries the first announcement after the first keystroke was more like, see and hear in oblivious.mp4.

But the thing i wonder if we follow the idea to make those "call to action"/"recommendation" in random order is it then really necessary to provide a list of all four recommendations (or in case the list is extended by a contrib module there will be even more) it might be overwhelming and hard to memorize all of them at once. would it make sense and be technically possible to announce the first recommendation right after "password secure edit text with autofill menu" and not only after the first keystroke? so the user knows i am in a password field and i should add a number first for example ( another time the first recommendation would be start adding a lowercase letter for example). that way it would be a guided experience in case someone doesnt use a password manager or the browser password autogenerate or alike?

and forgot to actually upload the two videos