Pull Request resolves #48395.
Improves accessibility of the "Set the password for your Super User account" field during Joomla installation and other areas of the interface that have a password-strength requirement. Screen reader users now receive the password length requirement and their progress while typing, such as “10 out of 12 characters entered.”. Previously, all that was conveyed was: "Password does not meet the site's requirements" without any further explanation or context, even though the password meter visually indicated the user's progress to entering a sufficient password. Additionally, language strings were added so that the status messages are translated as necessary dependent upon installation language.
Note that this is a targeted fix for password strength on the installer page, but if there are other forms using the shared password-strength script, they should be reviewed also to ensure no regressions have been introduced.
The new behaviour is as such:
Below is an image containing the speech output from NVDA that shows what the interaction is conveyed as verbally:

This a complex interaction and requires a screen reader and many steps in 3 phases. (NVDA, VoiceOver, and Narrator are suggested.)
Phase 1
Phase 2
Phase 3
The following image depicts speech output from NVDA when encountering a custom password field set up by the site admin. Note that the output matches the password description exactly.
I have tested this with NVDA and Narrator in Chrome, Edge, and Firefox.
The password length requirement is announced when entering the field when there is no input in it, but it is not included in the feedback while typing. Users hear that their password does not meet the requirements without being reminded of the required length or their progress.
Screen reader users hear the requirement and their progress while typing. The incomplete password message is not repeated with every update. The existing instructions are not duplicated visually, and password validation continues to work. A more robust experience for screen reader users is achieved.
Please select:
Documentation link for guide.joomla.org:
No documentation changes for guide.joomla.org needed
Pull Request link for manual.joomla.org:
No documentation changes for manual.joomla.org needed
Just trying to help.
How can I differentiate it then so that the implementation can be used only for this field? If used elsewhere, can the same rules apply? Trying to improve the user experience for screen reader users here, not cause major headaches. If you have implementation advice, I'll gladly receive it.
why are you looking to restrict it to the installation? If its an accessibility problem when the passwordfield strength field is used in the installer then it is obviously therefore a problem everywhere the same field is used and that could be in the context of the installation, site and admin - probably not the cli but i would need to check
OK so given that the field exists in multiple places:
Why is it a no?
It's not definitely a no.
From what I can piece together here, I'll need to add a character count key in 3 different files so that it's not installer specific while also registering it in the /form/fields/password.php, thus removing the dependency on the installer language string and, ideally, remove the risk of causing issues to those particular fields with passwordstrength. Does that sound reasonable?
the change must be made everywhere or nowhere
I tested the latest commit in various places and it looks to be conveying the requirements accurately across templates, not just the installer. Is it now worth reviewing?
Image below shows output from NVDA speech viewer after setting custom rules in the admin template for password strength. All of them are conveyed properly:
you need to test it more carefully
for example set it to
Minimum Requirements — Characters: 12, Numbers: 1, Symbols: 1, Upper Case: 1, Lower Case: 1
then enter 1 character
it announces
Minimum Requirements — Characters: 12, Numbers: 1, Symbols: 1, Upper Case: 1, Lower Case: 1 1 out of 12 characters entered.
and when you reach 12 characters it stops counting completely
do you really need to announce the requirements on every key press. The requirements are already in the field description - seems overly verbose to me but I'm not the accessibility expert that you are
probably beyond the scope but shouldnt <meter be accessible - it has no name or if its not interesting it should be aria-hidden and it probably should be a <progress anyway not a <meter
you need to test it more carefully
for example set it to Minimum Requirements — Characters: 12, Numbers: 1, Symbols: 1, Upper Case: 1, Lower Case: 1
then enter 1 character it announces Minimum Requirements — Characters: 12, Numbers: 1, Symbols: 1, Upper Case: 1, Lower Case: 1 1 out of 12 characters entered.
So it conveys that there's only one character that has been entered out of twelve. That's correct, isn't it? The visually displayed information is being conveyed at every point. There's also no visual indicator of whether you've satisfied any of the additional password requirements, so screen reader users wouldn't have access to that either (Imagine an announcement like "You've entered 0 out of 1 required Uppercase letters" and so on for every condition...it would become too much.)
and when you reach 12 characters it stops counting completely
That's because there isn't any change that occurs after the password has been accepted visually either. After the password has been accepted, that text stays static and no other changes occur. It's up until the satisfaction point that needs to be conveyed.
do you really need to announce the requirements on every key press. The requirements are already in the field description - seems overly verbose to me
They're in the field description and conveyed only when you focus the field with a screen reader. If you're blind, you only access that information once. Same if you have a cognitive disability and use a screen reader. Compare this experience to one without this PR: users access the field description once and then when they're entering their password they're only told it doesn't meet site requirements. That's not very helpful when sighted users see the permanently visible description.
but I'm not the accessibility expert that you are
Is this sarcasm?
seems wrong to me but i;m not the expert
seems wrong to me
Happy to answer any other questions you have.
but i;m not the expert
Again, sarcasm?
no sarcasm - youre the expert not me. just seems very wrong
| Category | ⇒ | Administration Language & Strings Installation Layout JavaScript NPM Change |
| Title |
|
||||||
Come on. This is so obviously wrong it's a joke. Not wasting my time but just think about it for more than 5 seconds - hint this field is obviously used in more places than the installation so just adding a string in the installation language file will obviously cause problems when the field is used when that string is not present - you really cant just hack together a fix for something without considering the implications everywhere the field would be used.!!
Do you really consider this to be a useful improvement