related to #13907

Small update on the layout:
If you click on the Alert Button in the topbar the alerts should appear in the same manner like they were displayed before. Additionally there can be a "hide all" button.

Before

After

Certainly better than the current position.

Previous arguments against moving them from center was that they would be away from the users focus. Personally I don't see this as an issue.

I don't think it's better, just different. Now they will cover different buttons ("Apply Patch" in Patchtester, "Options" and "Help" buttons in all components, ...).
Imho the real problem is that they hover over the other content and have a fixed width which is to narrow. Solve those two and the possition doesn't matter anymore (center is fine then).

On a sidenote, the notification/alert button in the toolbar relates to postinstall messages. They have nothing to do with regular messages shown.

Giving the alerts an absolute position (current/hover) will always pose an issue regards covering content. The only alternative I guess is to revert back to static positioning (3.7).

A step forward are to avoid Mesages like "Article saved" > only necessary Messages should be shown.

The only alternative I guess is to revert back to static positioning (3.7).

As I understood the reason for the current hovering alerts was that you also see them if you scrolled down a page. But that could also achieved by having a "sticky" message container. Similar to what we do with the topmenu/toolbar in J3 which are always visible

A step forward are to avoid Mesages like "Article saved" > only necessary Messages should be shown.

And how would you know if the article got saved? Just assuming because the page reloaded? Doesn't sound like a good diea to me.

If an Article couldn't be saved comes a Message, otherwise it is saved.

If an Article couldn't be saved comes a Message, otherwise it is saved.

And how do you know if the request really went through? My internet here is so fast, sometimes I barely notice a page reload. And I would hate to check each time if the browser icon really changed when I hit that save button.

You're right, to be sure a Feedback is necessary. Me bothering the shifting of Interface by 3 Words in 2 Rows. I prefer for Example a green Background in Title-Field.

...could also achieved by having a "sticky" message container.

Sounds a viable option

On a sidenote, the notification/alert button in the toolbar relates to postinstall messages. They have nothing to do with regular messages shown.

That needs maybe a new concept then? Why are these messages so important? We could redirect to them after the install?

@coolcat-creations @ciar4n let me know if we need the hide all option

Why are these messages so important?

Most of them aren't that important (imho), but some may be.
In J3 we show a big message in the Control Panel when there are such messages, but nowehere else.
In J4 it's now this tiny "alert" icon and no longer that big messages. Less intrusive but available on each page.
There are pros and cons for each way I guess ?

I think we take here some space which can be used for other things better.
The after Installation messages can be shown after the installation and the administrator has to approve he read it. It´s like in the bank account that you confirm you read the news or when any service has new ToS.
This icon would be perfect for the case I thought it is for :-)

So I noticed yesterday also that the notices are annoying :) Here is what I got after an update of a language pack:

So I agree with the proposal here. I read there is also a 5-second timeout, that would be great.

Removing an alert after a time period is not accessible
https://www.w3.org/TR/wai-aria-practices/#alert

Thanks for the info.

I read there is also a 5-second timeout

Actually for the reason that @brianteeman mentioned above this feature is removed in the updated code! We still have to reflect that to core.js (once we'll do the new release of the component elements)

@infograf768 Please add Label "J4 Backend Template". Thanks for adding Labels so far and in Future ;)

Please remember, in case alerts are displayed to the right side for LTR, to display them to the left side in RTL. The main reason is to prevent the alerts from hiding the admin menu.

Everything about the current alerts is not accessible.
They are not only displayed wrong for the wrong situation but also not accessible at all.
If anyone has an idea how to programmatically solve it would be higly appreciated.

it is easy to do as long as we abandon the completely broken web component that is being used. However that is nothing to do with this issue.

If the design calls for them to be on the right then this should stay open. If not then it should be closed.

Please remember that the biggest problem is that the majority of these popup alerts should not even be alerts at all

The only alternative I guess is to revert back to static positioning (3.7).

+1 for that.

As I understood the reason for the current hovering alerts was that you also see them if you scrolled down a page.

Most messages appear after page reload that means the page is at top position where the message container should be. I read them and scroll down and can go on. I don't see any benefits to have these messages glued annoyingly over the content and to close them again and again and again and again before you can go on with your work.

But that could also achieved by having a "sticky" message container.

-1 because that doesn't change anything. Because you can't scroll them away.

Add a setting to the backend template with options "Annoyingly glued message container" "Static message container at top of the page without "modern" falderal"

falderal ?

https://dictionary.reverso.net/english-definition/falderal

cool - learnt a new word

So what we need to solve is:

• exception handling -> show the right alerts / warnings / informations / errors for the right case @?
• position and "animation" -> show it in the right place without moving the content down @?
• design -> make a designproposal that fits to the new backend @coolcat-creations

Before doing a design proposal I would need the advise of the developer which exeptions exists and if we have the possibility for different appeareance to display them.

• Can Fatal Errors be still shown as Popup in a a11y way?
• Can Warnings be displayed in a static position? Can we add individual messages to the warnings and errors to help users how to solve things and add links to the backend where to solve? For example: Plugin xy is not active - Click here to enable it
• Can a information like "Saved" be shown even more reduced and dissapear after a while?

Does anyone have any recommendations or useful links about a11y alerts?

all is possible.

After seeing your repo and the accessibility failures in the work done so far design proposals are a waste of time if there is no commitment to basic accessibility. You dont add accessibility on as afterthought it has to be done from the beginning. The template proposal is far more than a design and is not the same as your proposal in the magazine. Sorry but you chose to exclude people with the skills and knowledge for 4 months. Too late now for me.

Every attempt to cowork with you like with an adult fails unfortunately (see just your answer right now). No wonder I don't want to work in this repo and prefer to ignore you.

and thats why you make so little progress

Open Source matters

Not sure what you are refering to and why you are all the time such an unkind and sarcastic person @brianteeman but this thread shows me that its better to ignore you again. I feel sorry for you, that you can't be a nice person.

+1 for "Save"-Message without moving Content.

It's really quite simple.

1. The current code is misusing the term role=alert - see https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alert_role for when it should be used and you wil see.

The alert role is used to communicate an important and usually time-sensitive message to the user. When this role is added to an element, the browser will send out an accessible alert event to assistive technology products which can then notify the user about it. The alert role is most useful for information that requires the user's immediate attention, for example:

• An invalid value was entered into a form field
• The user's login session is about to expire
• The connection to the server was lost, local changes will not be saved

Because of its intrusive nature, the alert role must be used sparingly and only in situations where the user's immediate attention is required. Dynamic changes that are less urgent should use a less aggressive method, such as aria-live="polite" or other live region roles.

2. When you understand when there should be an alert you will see that a success message is not an alert
3. Do we even need a message to say "this has been saved"? If you think we do (I dont) then that would not be an alert and does not need to be a dismissable popup. It should only be a piece of information that is displayed. The only time that I can see a use for a success message would be when you are an in an item and press "save and continue". All other actions already result in a page load or new page and you would only need to know if the action had failed.
4. The popup is using colour alone to indicate meaning. There should be a second visual indicator such as an icon

Do we even need a message to say "this has been saved"? If you think we do

Agree.

To be clear. Most of the "alerts" are not alerts and should not have a role=alert. They are user notifications only.

https://www.w3.org/WAI/tutorials/forms/notifications/

Success messages should be kept as Notices, not alerts.

Success messages should be kept as Notices, not alerts.

Also Warnings are not alerts. Or sometimes I cannot see why something ist an alert and not an error. For example administrator login. An empty input is a error -> alert. It the user is not authorised to login, it is a warning. But the same effect: The user canniot log in.

@chmst the problem comes from a misunderstanding of the bootstrap class=alert which has been converted to role=alert

There is a great article here https://inclusive-components.design/notifications/ and as it shows most of the time the things we call "alerts" are really "notifications". So we need a way to differentiate our messages between alerts and notifications AND a way to differentiate between alerts that require an action in the alert (alert-dialog) and alerts that are fyi

So I think that notifications can disappear after a given time of a few seconds. I also like the design, where notifications appear at the right side as we are already used to get notifications there.
How we handle alerts is another question. They may not disappear and request an action.

I admit that I dont see the consequences for screenreaders and keqboard users. The error-message (alert) must get the focus, but notifications may not take the focus .

Suggestion: In the red area we have space to display System messages without moving content around and without overlaying current content.
There can be a messagebox added for any kind of notifications. For real fatal errors a popup with drop in background can apear.

Mind: the red box is just marking the space - thats not a layout proposal :-D

@chmst it is mainly about focus - do they take the focus or not. Sites often use aria-live to announce an alert etc to a screenreader user without taking the focus BUT i dont think that applies in our case as we only display them on a page load and not "live"
Its also about how you are able to dismiss those that take focus. The escape key should be able to dismiss/close not just a close button

@coolcat-creations as long as the messages fit in the area thats fine

@brianteeman for that we would need to collect possible messages. Thinks like "Saved!" would absolutely fit in there but we need to seperate the fatal errors from the notices to see what could possibly appear there. Another possibility would be to truncate the messages after x characters and allow the user to expand the message to read more.

Set to "closed" on behalf of @alikon by The JTracker Application at issues.joomla.org/joomla-cms/16497

related to the old template, open a new issue if needed

related to the old template, open a new issue if needed