Password suggestions are hidden from screenreaders

Created on 29 March 2022, over 2 years ago
Updated 11 July 2024, 7 days ago

Problem/Motivation

I became more aware of screenreaders lately and the potential underlaying problems and roadblocks interacting with a webinterface. When reading the following article https://incl.ca/show-hide-password-accessibility-and-password-hints-tuto... (the linked website is currently unavailable due to a database error here is an alternative link on archive.org) I've tested the password suggestions functionality in the Drupal admin (I've used Claro as the admin theme) to see if it is accessible with VoiceOver in MacOS. Problem is the password suggestions box is placed after the password input field, it isn't associated with the input field in any way and there is also no feedback if one of the password suggestion constraints is met.

Steps to reproduce

- go to user/1/edit or admin/people/create
- interact with the page with a screenreader (VoiceOver in my case)
- tab until you reach the password field and start to enter a password
- tab to the confirm password field
- You will notice there won't be any feedback in regards of your input in the context of the password suggestions nor an announcement that there are any password suggestions until you reach them.

Proposed resolution

The previously mentioned article by Nicolas Steenhout already contains a few approaches how to improve the experience and the interaction for screenreader users. for example:

- place the password hints before the password input field instead of after it.
- associate the the password hint with the input using the aria-describedby attribute

And i have to admit i like the idea to prepend the list of password suggestions in paragraph form with the visibility-hidden css class before the visually visible password suggestions list.

p.s. i am not sure which component would be the most appropriate for this issue. i went with user system component cuz it applies to claro and seven both using seemingly the same pattern.

πŸ› Bug report
Status

Needs work

Version

11.0 πŸ”₯

Component
User systemΒ  β†’

Last updated about 6 hours ago

Created by

πŸ‡©πŸ‡ͺGermany rkoller NΓΌrnberg, Germany

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

    I think this just falls under WCAG 1.1.1.

  • πŸ‡ΊπŸ‡ΈUnited States nilubol

    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.

  • πŸ‡©πŸ‡ͺGermany rkoller NΓΌrnberg, Germany

    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.

  • πŸ‡ΊπŸ‡ΈUnited States neclimdul Houston, TX

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

  • πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

    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.

  • πŸ‡ΊπŸ‡ΈUnited States neclimdul Houston, TX

    neclimdul β†’ changed the visibility of the branch 3272325-password-suggestions-are to hidden.

  • πŸ‡ΊπŸ‡ΈUnited States neclimdul Houston, TX

    neclimdul β†’ changed the visibility of the branch 3272325-password-suggestions-are to hidden.

  • πŸ‡ΊπŸ‡ΈUnited States neclimdul Houston, TX

    neclimdul β†’ changed the visibility of the branch 3272325-password-suggestions-are to active.

  • Merge request !7269Improve a11y of Password Suggestions β†’ (Open) created by neclimdul
  • Pipeline finished with Failed
    4 months ago
    Total: 168s
    #134616
  • Status changed to Needs review 4 months ago
  • πŸ‡ΊπŸ‡ΈUnited States neclimdul Houston, TX

    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.

  • Pipeline finished with Failed
    4 months ago
    Total: 689s
    #134625
  • Status changed to Needs work 4 months ago
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Appears to have some javascript test failures.

  • Status changed to Needs review 4 months ago
  • πŸ‡ΊπŸ‡ΈUnited States neclimdul Houston, TX

    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.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

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

  • πŸ‡©πŸ‡ͺGermany rkoller NΓΌrnberg, Germany

    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.
  • Status changed to Needs work 2 months ago
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Thanks @rkoller for the great detail!

  • Pipeline finished with Failed
    about 1 month ago
    Total: 181s
    #198330
  • πŸ‡ΊπŸ‡ΈUnited States neclimdul Houston, TX

    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.

  • πŸ‡ΊπŸ‡ΈUnited States neclimdul Houston, TX

    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.

  • Pipeline finished with Failed
    8 days ago
    Total: 553s
    #221059
  • πŸ‡©πŸ‡ͺGermany rkoller NΓΌrnberg, Germany

    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?

  • πŸ‡©πŸ‡ͺGermany rkoller NΓΌrnberg, Germany

    and forgot to actually upload the two videos

  • πŸ‡ΊπŸ‡ΈUnited States neclimdul Houston, TX

    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.

Production build 0.69.0 2024