Blind and Visually Impaired Community
↑
4
↓
Accessible behavior for new password requirements? (self.Blind)
submitted by bowlofsoup8
Hi all,
I am in the accessibility field and pretty confident using a screen reader. However, I am struggling on finding documentation for the expected behavior for accessible password requirements. This is a list with items like ‘at least 8 characters,’ ‘one number,’ and ‘one special character.’ These have a checkbox that shows checked or unchecked if the requirement is met or not. The user cannot check or uncheck these, but a sighted user can see them change as they type out a new password that meets the requirements. (I don’t need advice on digital accessibility basics like alt text.)
On a page, the reading order would be:
1. Existing (old) password field
2. New password field
3. Password requirements text
4. Confirm new password field
I’m thinking an aria-live polite region could work, but am not sure what exactly to announce. I have seen $1 but it is not exactly the same, and WCAG doesn’t have guidelines for this specific situation.
I am also considering moving the password requirements to be above the first New Password field. Would this work better than creating an aria live region, as screen reader users can simply navigate back up to the requirements to see which are satisfied?
I’d appreciate any input from experienced screen reader users and/or accessibility experts. Thank you!
I am in the accessibility field and pretty confident using a screen reader. However, I am struggling on finding documentation for the expected behavior for accessible password requirements. This is a list with items like ‘at least 8 characters,’ ‘one number,’ and ‘one special character.’ These have a checkbox that shows checked or unchecked if the requirement is met or not. The user cannot check or uncheck these, but a sighted user can see them change as they type out a new password that meets the requirements. (I don’t need advice on digital accessibility basics like alt text.)
On a page, the reading order would be:
1. Existing (old) password field
2. New password field
3. Password requirements text
4. Confirm new password field
I’m thinking an aria-live polite region could work, but am not sure what exactly to announce. I have seen $1 but it is not exactly the same, and WCAG doesn’t have guidelines for this specific situation.
I am also considering moving the password requirements to be above the first New Password field. Would this work better than creating an aria live region, as screen reader users can simply navigate back up to the requirements to see which are satisfied?
I’d appreciate any input from experienced screen reader users and/or accessibility experts. Thank you!
Marconius 4 points 1y ago
I would put the requirements before the New Password field so users who are navigating linearly can encounter them and understand them first before trying and failing at creating a new password. You can also add an aria-describedby on the New Password input field and point it at the id of the paragraph containing the requirements to bolster it if they jump directly to the field.
If you have something that appears saying that passwords don't match or that they don't satisfy the requirements use aria-live="assertive" to make sure the alert is noticed. However, do Not do a constant validation since that gets ridiculously annoying when trying to type. Validate it after focus moves off the input fields and then we can go back and fix the error.
Make sure to add in functionality to show the passwords if the user needs that function, and do not suppress copy/paste commands between the fields.
If you have something that appears saying that passwords don't match or that they don't satisfy the requirements use aria-live="assertive" to make sure the alert is noticed. However, do Not do a constant validation since that gets ridiculously annoying when trying to type. Validate it after focus moves off the input fields and then we can go back and fix the error.
Make sure to add in functionality to show the passwords if the user needs that function, and do not suppress copy/paste commands between the fields.
bowlofsoup8 [OP] 1 points 1y ago
Lots of good points, thank you!
ke7zum 2 points 1y ago
I would actually put it below the first password field as I do travel down below before writing the text then hit fshift e or what ever for my screen reader to get to that first field. Youu coudl have a check mark for the stuff taht has been met aned nothing, or an error above the password field with the missing requirements.
retrolental_morose 3 points 1y ago
I'd personally implement a role="progressbar" for this. This way, the screen reader isn't announcing unusual or complex data during password entry, but it is clear to the user that progress either is being made or requirements are met. I'd put the textual representation of the requirements before either field on the page and ensure you render completion state of each element with an indicator that is verbal to most screen readers (not all unicode check symbols are read by all synthesizers), and ensure that if there are missing elements within the password the tabindex of that data is between the password and the submit button so the user, even if they are only navigating with tab, can hear the missing information..
bowlofsoup8 [OP] 3 points 1y ago
Thanks so much! That’s super helpful. Thanks for the tip on unicode, I plan on assigning an aria label or alt text (depends on final choice of visual checkbox display) with something like “Satisfied” or “Missing” to note the state of each requirement.
I will move the requirements before the New Password field so users can review them before choosing their new password. I’m not sure on putting the requirements tabindex between the password and submit button, because that would violate the rules for focus order. (Tabbing forward would go backwards in the reading order.)
But, I can ensure clear, dynamic error text that appears as an aria-live polite region when focus leaves the New Password box, so the user can fix the error before submitting. I could disable the submit button until the requirements are met, would that be useful? (I’m personally annoyed by disabled fields when using a screen reader as I rely heavily on the tab key with forms and tend to not realize where buttons are. But I’m also just at an intermediate skill level with navigating by screen reader alone.)
I will move the requirements before the New Password field so users can review them before choosing their new password. I’m not sure on putting the requirements tabindex between the password and submit button, because that would violate the rules for focus order. (Tabbing forward would go backwards in the reading order.)
But, I can ensure clear, dynamic error text that appears as an aria-live polite region when focus leaves the New Password box, so the user can fix the error before submitting. I could disable the submit button until the requirements are met, would that be useful? (I’m personally annoyed by disabled fields when using a screen reader as I rely heavily on the tab key with forms and tend to not realize where buttons are. But I’m also just at an intermediate skill level with navigating by screen reader alone.)
retrolental_morose 3 points 1y ago
I think a disabled next button is preferable to having to reenter a password which you know has already failed, yeah. :) But I'm just a user.
MostlyBlindGamer 2 points 1y ago
This sound like a reasonable approach. When looking for more info on this, I'd focus on form validation, requirements and errors.
bowlofsoup8 [OP] 2 points 1y ago
Thank you!
TechnicalPragmatist 2 points 1y ago
Before sounds better because you know what you are going in to I would think.
Also typically these check boxes are not read by screen readers and I didn’t know that’s how it works and that was what was going on but that makes sense. I would like to know if the check boxes are fulfilled. For now the only way I would know if my password failed after I hit submit. So verbalizing these would be wonderful. I think the check boxes would be wonderful information blind people don’t usually have access to.
Also typically these check boxes are not read by screen readers and I didn’t know that’s how it works and that was what was going on but that makes sense. I would like to know if the check boxes are fulfilled. For now the only way I would know if my password failed after I hit submit. So verbalizing these would be wonderful. I think the check boxes would be wonderful information blind people don’t usually have access to.
This nonprofit website is run by volunteers.
Please contribute if you can. Thank you!
Our mission is to provide everyone with access to large-
scale community websites for the good of humanity.
Without ads, without tracking, without greed.
scale community websites for the good of humanity.
Without ads, without tracking, without greed.
©2023 HumbleCat Inc • HumbleCat is a 501(c)3 nonprofit based in Michigan, USA.