Hi, could you explain why this should be a setting/preference in MediaWiki and not in the screenreader software instead?
What is special about MediaWiki websites compared to other websites, when it comes to alerts on websites?

For the records, https://www.w3.org/TR/wai-aria-practices/#alert says "they may trigger an alert sound".

A screen reader has no knowledge about what is and what is not a warning message, except for the standard dialog boxes. I'm not sure we use those, perhaps someone should check.

My interest in this is only to convey the meaning in Mediawiki, not to unify the virtual world.

@jeblad I have guesses on such software shortcomings, but as it's not even clear from current task description on which software project in MW you are referring to, I'd like to ask you for at least one, better several examples where alerts and messages fail in order to pinpoint working areas.

In T214953#4918080, @jeblad wrote:

A screen reader has no knowledge about what is and what is not a warning message

This is probably mostly about https://www.mediawiki.org/wiki/OOUI/Windows/Dialogs nowadays as MW is moving towards OOUI, so this might be a subset of T145036 ?

One such message, that could be an example, is the warning message that comes when the console state is cleared in Scribunto. This message is triggered by previous changes in the module code.

mw:Extension:Scribunto has a warning message (code) that is posted as a slight change to the DOM, but has a rather nasty implication. It is not obvious it will be "seen" by someone visually impaired or blind.

Similar warning messages are posted in other parts of the code.

In general some code is injected in the DOM and the user is expected to see the changes, but if the user is not able to spot the changes, then the user can't act upon the warning message.

I wonder if this is the quite common assumption "what I see and what I hear is what everybody else see and hear". That assumption is simply wrong, but is quite common.

Please provide a clear list of steps (step by step, including URLs) that allow someone else to see that warning message, without any need for interpretation which exact steps are needed for someone else to see that warning message somewhere. See https://www.mediawiki.org/wiki/How_to_report_a_bug for more information.

The common assumption that programmers in fact knows how the system they create works… ;)

Go to a random non-existing module page on Wikipedia (like this) and click [create]

Add the code

return { foo = 'bar' }

Down in the console write

=p.foo

and press [enter]
Go back up in the code and change it to

return { foo = 'bar' }

Now click in the debug console. A warning message will now be added to the DOM, and even if it is quite visible it is not for a blind coder. (It is not that likely we have blind coders, but they do exist, and this is just an example.)

In T214953#4919371, @jeblad wrote:

The common assumption that programmers in fact knows how the system they create works… ;)

[OT] As long as tasks get created that lack clear steps to reproduce for a "programmer" (as requested in https://www.mediawiki.org/wiki/How_to_report_a_bug linked on top of the task creation form ), these "programmers" (who indeed might know "how the system works") might however not know what you're exactly talking about. That's why there is https://www.mediawiki.org/wiki/How_to_report_a_bug which saves some forth-and-back (if not ignored when creating tasks).

If I get your previous comment correctly, this task is only about messages printed in the web browser's "Developer Tools", and not about any messages displayed on a web page generated by MediaWiki itself?

No.

In some cases (all?) warning messages and dialogs should sometime beep when they are created or made visible.

and

One such message , that could be an example, is the warning message that comes when the console state is cleared in Scribunto.

It is an example

As long as you don't provide a clear definition of "some messages" that you have in mind I am afraid that this task is unfixable, as it might cover anything across very different code bases and even applications (random debug spew in error consoles that only tech-savvy users are ever going to see, some but maybe not all MediaWiki dialogs, some but maybe not all OOUI based dialogs, maybe something else, who knows).

IMO it's as non-actionable as "make everything somehow translatable" or "fix all wrong documentation" without being more specific.

What makes this stalled?