avatar mbeganyi-a11y
mbeganyi-a11y
21 Oct 2026

Pull Request resolves #48395.

  • I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.

Summary of Changes

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:

  1. Focusing the field conveys that 12 characters are required for the password by means of the description associated with the field.
  2. Entering one character then ceasing typing results in "Password does not meet the site's requirements. Enter at least 12 characters. 1 out of 12 characters entered."
  3. Characters 2–11 result in "Enter at least 12 characters. x out of 12 characters entered." where x represents the number of characters.
  4. Password completion is conveyed as "Password accepted"
  5. Deletion of a single character from the 12 character password results in: "Password does not meet the site's requirements. Enter at least 12 characters. 11 out of 12 characters entered."
  6. Deletion of more characters results in "Enter at least 12 characters. x out of 12 characters entered." where x represents the number of characters.
  7. Deletion to zero characters results in no announcement.

Below is an image containing the speech output from NVDA that shows what the interaction is conveyed as verbally:
NVDA speech output of password field

Testing Instructions

This a complex interaction and requires a screen reader and many steps in 3 phases. (NVDA, VoiceOver, and Narrator are suggested.)

Phase 1

  1. Start a new Joomla installation with this PR applied.
  2. Once installed, enable a screen reader and proceed past the first step of installation (Name of your site) to the Super User account setup
  3. Navigate to the "Set the password for your Super User account" field. Confirm that the password-length requirement is announced.
  4. Enter one character and stop typing. Listen for the announcement. It should be "Password doesn't meet the site's requirements. Enter at least 12 characters. 1 out of 12 characters entered."
  5. Enter fewer than 12 characters. Note that the “Password doesn't meet the site's requirements” was only announced once. Now the announcement is "Enter at least 12 characters. x out of 12 characters entered." where x represents the number of characters.
  6. Continue typing until 11 characters and stop. The message conveyed should be: “Enter at least 12 characters. 11 out of 12 characters entered.”
  7. Continue typing until the password reaches 12 characters. Confirm that the completion message is announced.
  8. Delete one character to bring the number to 11. The announcement should be: "Password doesn't meet the site's requirements. Enter at least 12 characters. 11 out of 12 characters entered."
  9. Delete characters to bring the password below 12. Confirm that the requirement and progress feedback return.
  10. Stop typing. Confirm that announcements do not keep repeating.
  11. Confirm that the password requirement is not duplicated visually.
  12. Confirm that an insufficient password still prevents you from continuing.

Phase 2

  1. Complete the Joomla installation and continue to another field that has a password strength feature, such as Users > Manage > [username] > Password
  2. Ensure the same behaviour as mentioned with the Installer > Super User password field from Phase 1 is present.

Phase 3

  1. Set up custom password requirements within the Users > Manage > Options > Password Options section. (For example, Minimum Numbers set to 3, Minimum Upper Case set to 2.)
  2. Save and Close from the custom options and return to the Users > Manage > [username] > Password field
  3. Ensure that your custom password options are announced by the screen reader in the same fashion as Phases 1 and 2.
  4. Congratulate yourself for completing this testing regimen.

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.

Custom fields are successfully described and conveyed

I have tested this with NVDA and Narrator in Chrome, Edge, and Firefox.

Actual result BEFORE applying this Pull Request

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.

Expected result AFTER applying this Pull Request

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.

Link to documentations

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

avatar mbeganyi-a11y mbeganyi-a11y - open - 21 Oct 2026
avatar brianteeman
brianteeman - comment - 21 Oct 2026

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

image
avatar mbeganyi-a11y
mbeganyi-a11y - comment - 21 Oct 2026

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.

avatar brianteeman
brianteeman - comment - 21 Oct 2026

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

avatar mbeganyi-a11y
mbeganyi-a11y - comment - 21 Oct 2026

OK so given that the field exists in multiple places:

  1. Is it possible to apply the fix in one place to reach all of them successfully and give the user the same experience? Seems like a no.
  2. If not, what's the best way to distinguish the fields so that the ones with passwordstrength receive the same treatment and the others are untouched?
avatar brianteeman
brianteeman - comment - 21 Oct 2026

Why is it a no?

avatar mbeganyi-a11y
mbeganyi-a11y - comment - 21 Oct 2026

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?

avatar brianteeman
brianteeman - comment - 21 Oct 2026

the change must be made everywhere or nowhere

avatar mbeganyi-a11y
mbeganyi-a11y - comment - 21 Oct 2026

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:

Speech output after setting custom password requirements
avatar brianteeman
brianteeman - comment - 21 Oct 2026

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

avatar brianteeman
brianteeman - comment - 21 Oct 2026

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

avatar brianteeman
brianteeman - comment - 21 Oct 2026

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

avatar mbeganyi-a11y
mbeganyi-a11y - comment - 21 Oct 2026

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?

avatar brianteeman
brianteeman - comment - 21 Oct 2026

seems wrong to me but i;m not the expert

avatar mbeganyi-a11y
mbeganyi-a11y - comment - 21 Oct 2026

seems wrong to me

Happy to answer any other questions you have.

but i;m not the expert

Again, sarcasm?

avatar brianteeman
brianteeman - comment - 21 Oct 2026

no sarcasm - youre the expert not me. just seems very wrong

avatar mbeganyi-a11y mbeganyi-a11y - change - 22 Oct 2026
The description was changed
avatar mbeganyi-a11y mbeganyi-a11y - edited - 22 Oct 2026
avatar joomla-cms-bot joomla-cms-bot - change - 22 Oct 2026
Category ⇒ Administration Language & Strings Installation Layout JavaScript NPM Change
avatar mbeganyi-a11y mbeganyi-a11y - change - 22 Oct 2026
Title
…
[6.3] Install Joomla: setup Super User password: Number of characters and requirements conveyed to screen readers
[6.3] Password strength fields: Number of characters and requirements conveyed to screen readers (Installer, Admin, User)
avatar mbeganyi-a11y mbeganyi-a11y - edited - 22 Oct 2026
avatar mbeganyi-a11y mbeganyi-a11y - change - 22 Oct 2026
The description was changed
avatar mbeganyi-a11y mbeganyi-a11y - edited - 22 Oct 2026

Add a Comment

Login with GitHub to post a comment