@Quy - thanks

Doing it this way it would be good for accessibility if there was an option on a per user setting to

• disable autodismiss

• alter the time setting

• bonus would be for a media query that disables the autodismiss if the user has their system set to prefers-reduced-motion - this can be done with a media query

@brianteeman autodismiss is a a11y "problem" correct? so user setting for the complete code base would be great (even if it's not a a11y thing)

autodismiss is a a11y "problem" correct?

It's not an issue for screen readers but it is an a11y issue for everyone else - thats why I suggested the 3 things above - or did you mean something else?

Just repeating here what I wrote above in #27213 (comment) so that it gets in the general discussion:

Agree concerning adding parameters. But, more than that, some alerts may need time to read and others not (See changing default language for example). Ideal may be to change parameters per alert. A bit complex maybe.

@infograf768 those messages should not be an alert. alert has a specific meaning

@brianteeman That's what I mean. Ok I'm in favor for user parameter, I'm not sure if it makes sense to configure the time frame. As jm mentioned maybe the developer defines the time till it get closed. In a more sophisticated (or over-engineered) way we could have 3 setting "short" "medium" "long".

How can you disable such a function with a media query?

@infograf768 those messages should not be an alert. alert has a specific meaning

Whether they are alert for errors, warnings or important infos, they are displayed the same way and J3 was much more friendly for these.

The time frame is a user setting not a developer setting . A developer should not be deciding how long someone will need to read a message as everyone is different. See https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-required-behaviors.html

The media query can be used with javascript, I believe the web component already uses the prefers-reduced-motion media query

How they are visually displayed should not mean that their code has to be the same. I have been saying for two years that we are abusing the role=alert (mainly due to a misunderstanding coming from bootstraps use of class=alert. An information message is not an alert. You are correct that these information messages should not autodismiss

the developer can help based on "how long the text is" to read. That's why I suggested "short,medium,long". But it's too much anyway.

not really helpful and wouldnt satisfy the a11y requirement. At the end of the day a very long message should probably not be an "alert" anyway

Even when it is a "real" alert, one has to be really fast to understand and click on the link for example in redirects...

It is still time to reconsider totally these pop-ups and re-implement what we had in J3?

no thats not an alert that is an alertdialog

Whatever it should be called, it still displays the same.

When it is a real alert (validation failing I guess can be considered as an alert), auto-dismiss implies to read extremely fast the message.
If we were using the same type of display as in J3, all these problems would just be gone.
<div id="system-message-container"> was a very good solution...

How it displays is irrelevant and the j3 method also failed on accessibility. The key to accessibility is can it be programmaticaly determined not if it can be determined by a human sense eg sight or sound.

There are three relevant "roles" here

role="status"

https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA22
To present status messages

role="alert"

https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA19

role = "alertdialog"

https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA18
requires interaction

@brianteeman @infograf768 the problem roots at

So the backend renders role="status" or role="alert" or role = "alertdialog" as they were the same thing. I propose to refactor this in a way that the above mentioned layout spits out 3 different custom element and make the needed changes in the core.js.

I can do a draft but my a11y knowledge is limited and that is obvious in the current state of the code here.

caveat with this approach is that the layout needs to sniff somehow the role...

(grrh I had a long answer written and github logged me out )

So the backend renders role="status" or role="alert" or role = "alertdialog" as they were the same thing.

I have pointed this out numerous times in the past and it comes from a misunderstanding of class="alert" in bootstrap.

I propose to refactor this in a way that the above mentioned layout spits out 3 different custom element and make the needed changes in the core.js.

I suggested that in #22507 but instead it was done in joomla-projects/custom-elements#119 which covers 2/3 roles.

I can do a draft but my a11y knowledge is limited and that is obvious in the current state of the code here.

I can easily check the draft for you. To be honest there isn't much too it but thats not the main issue.

The main issue is

caveat with this approach is that the layout needs to sniff somehow the role...

Most messages are created with enqueueMessage and we can sniff if they are set to info, error etc but because of the errors made in the past we might need to have an extra setting for the role if it doesn't match the default role (whatever that may be). This will need a manual review to achieve but actually shouldnt be too hard

Some messages are not created this way and probably dont use the layout either. These will have to be changed and they should have been changed anyway.

@brianteeman I'll take the blame for the current alert cluster$^^#. For some stupid reason (called DRY) I thought that I could combine all these into one element. Huge mistake, the behaviours are way too different to be be catered in a single codebase (eg the alertdialog needs to work as a modal = tabbing should be restricted in the modal).
About the ** enqueueMessage**: there are notifications that have links in them, that disqualifies them from notification as there is a user interaction in them...
That's what I meant with the sniffing part. If there is a button or link in the rendered notification then this needs to be elevated...

I am not sure we can easily sniff for that as it could be a $s in a language string

I am not sure we can easily sniff for that as it would be a $s in a language string

I'm pretty sure that when the string is evaluated we could check for a button/link in it

For sure when we have an alert-dialog, auto-dismiss shall not be used.
This does not solve the issue when the « alerts » are of another kind and stll need time to be read, Forcing auto-dismiss in this case maybe ok for some and not for others...

This does not solve the issue when the « alerts » are of another kind and stll need time to be read,

@infograf768 that's extremely easy to solve: count the characters and multiply them by a constant to get the time needed. There are solutions for everything, as long as you're willing to think outside the box...

count the characters and multiply them by a constant to get the time needed. There are solutions for everything, as long as you're willing to think outside the box...

Nice joke. I remind you it is Xmas now, not April 1st....
Btw, among the constants, don’t forget the age of the captain and his cholesterol level. ?

Btw, among the constants, don’t forget the age of the captain and his cholesterol level.

You see you totally lack imagination. The constant doesn't have to be the same for me and you, I might be faster on my interaction (thus also on my reading) and you might be extremely slow. That's not a problem there are ways to figure out the optimal constant for each user through browser heuristics or by using some own coded ones. I guess all these are way too much for you or the project...

count the characters and multiply them ...

If we go that way, I have a better idea:
before show a message to user we should run a school test for a "read speed" , and multiple the characters to the test result, of course we have to add to the result a heuristics predictions for user environment that can affect the read time, and not forget about a moon position

Sorry, that may sounds as good idea, but it is not. Problem not in the timing, but in concept in general.

https://ferdychristant.com/browser-heuristics-suck-7eca6c68e9fa

I guess all these are way too much for you or the project...

perfect guess.

There are solutions for everything, as long as you're willing to think outside the box...
You see you totally lack imagination.

Just got an imagination burst about thinking outside of the box (see: it took some time because my cholesterol level is high this morning...)

Happy new year to all

Test instructions updated. Please retest. Thanks.

@Quy for the media query take a look at joomla-projects/custom-elements#139

Updated. Thanks.

I hope this is better. Thanks again.

Maybe someone can convince the accessibility team to test this

I tested this and it worked - but I am not sure I like it. A selection of intervals from 1 to 5 (seconds) seems much too short. Steps of 5 seconds might be better, from 5 to 30.

I tested this and it worked - but I am not sure I like it. A selection of intervals from 1 to 5 (seconds) seems much too short. Steps of 5 seconds might be better, from 5 to 30.

Do we still need auto-dismiss now that alerts/messages are no more in pop-ups?

Autodismissing an inline alert would cause a shift in the content of the page. This would not only be bad ux but also an accessibility failure.

(Personally I still dont like the abandoning of popup alerts just because it was hard and hope it will make it into the actual release of joomla 4 in which case this code will be needed)

@brianteeman Do I understand you correctly that this PR breaks accessibility?