Password suggestions are hidden from screenreaders

I think this just falls under WCAG 1.1.1.

I tested keeping everything as-is and just adding aria-describedby to the password suggestion container, which does then expose this to screen readers. But, as mentioned, the placement and frequency with which this container updates isn't ideal.

If we keep the password suggestions where it is now (after the password fields), a user won't encounter this field until after they have already entered their passwords, rendering it useless or cumbersome to have to navigate back to update passwords. And as already mentioned by @rkoller, this can be missed by both sighted users as well as screen reader users.

If we move the password suggestions to above the password fields and leave it dynamic, the user will need to navigate past the (empty) suggestions box in order to get to the password fields. And because the list expands/contracts as you type in the password field, having this happen above the field you are typing in would be jarring to sighted users.

It seems that number four in @rkoller's list of suggestions makes the most sense here. A static, front-loaded passwords suggestion list reduces complexities and means that the user won't have to run through the password strength and list of requirements every time they type in the password field. Right now this content is being rendered in JS via user.theme.js so making this list static may also allow us to move this content into markup.

Additional usability review would be nice here. Sadly I just missed their office hours but adding the tag for visibility.

We have discussed the issue at 📌 Drupal Usability Meeting 2023-09-01 Needs work . 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.

Is the proposed resolution that was agreed to the static list?

We should definitely fix this. After listening to this page with a screen reader it clearly needs work. I think it was working better when we first introduced this in Drupal 7, but time erodes all things.

neclimdul → changed the visibility of the branch 3272325-password-suggestions-are to hidden.

neclimdul → changed the visibility of the branch 3272325-password-suggestions-are to hidden.

neclimdul → changed the visibility of the branch 3272325-password-suggestions-are to active.

Took a first pass at the proposal in the IS. Don't know if that was correct or not.

Couple changes:

1. Since this is structured, I used aria-details instead of aria-described by per the note on the aria-describedby mdn documentation https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attribut...
2. Added aria-live to the dynamically changing region

I also had to mangle things a bit to push an id onto the suggestions but I think this might make things a bit better by not replacing the entire wrapper div. This might allow the aria-live to actually work.

Appears to have some javascript test failures.

Fair enough.

However, I don't think I've really got a firm answer on the correct approach and I had to modify the proposed resolution so before I go diving into tests I'm going to move this back to NR to get some review on the approach.

Been about a month wonder if there someone that can be reached out to.

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 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 →

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 🐛 Password suggestions are hidden from screenreaders Active 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.

Thanks @rkoller for the great detail!

Took a stab at laying down some ground work for the suggestions. This actually is pretty cool because a lot of the hardcoded things that made it impossible to really theme or extend the password strength region are tied to the strength indicator so focusing on the suggestions allows it to be more extensible which can sort of be seen in the latest updates.

I don't claim this is a "good" implementation but it hopefully keeps things moving forward.

Would be great if someone could take a look at this and see if its on the right track before I spend too much time trying to polish it.

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

No worries! Thanks!

That's... interesting. It sounds like we're on the right track though so I'll take another pass at improving this.

Clearly relying on that live region isn't working out well. It looks like it doesn't announce anything if the removal is at the end and I suspect it doesn't behave all that well when the change is at the beginning and there are multiple items. That might be connected to the "oblivious" example as well, live regions and lists have been a source of frustration and I think nvda explicitly documents they might not work.

I'll poke around this time with direct announcements where we can control the behavior better. That will make things easier anyways since I can use devel_a11y to review things quicker.

My suggestion is to simplify and get rid of the live audio feedback altogether:

1. Just toggle an aria-invalid attribute on the field. Don't try to associate it directly with the dynamic suggestions.
2. After the field, where you have the validation error -- "Password does not meet the site requirements" -- make that a details/summary tag rather than plain text. That way the validation error, if present, will be the summary -- the next item in the tabindex for screen readers to find -- and users can choose to show the live validation list of remaining requirements in the <details> if they want.

Seems like a good approach to me @itmaybejj

To add some additional context:

• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attribut...
• https://caniuse.com/?search=aria-invalid