Comment 1 by jteh on 2012-06-13 03:57
Confirmed in Firefox 13. Appears to be fixed for Firefox 15 (not sure about 14).

NVDA doesn't currently support alerts and live regions in IE.

Comment 2 by jteh on 2012-08-01 23:18
Morphing ticket, since the Firefox issue is fixed in Firefox 15.
Changes:
Changed title from "role=alert text being read twice‏" to "role=alert not handled in IE"

Comment 3 by jteh on 2012-08-01 23:19
Changes:
Changed title from "role=alert not handled in IE" to "Support role=alert in MSHTML"

Comment 4 by nmatthews on 2013-04-16 15:40
I'm still seeing the dynamically generated text being read twice in Firefox 20.0.1

http://jsfiddle.net/LZfyk/

When the Simulate Errors button is pressed, NVDA speaks "I am some alert text. Alert. I am some alert text".

http://jsfiddle.net/K5H7v/37/

I've done some further investigation as well.

When the alert div contains the text directly, the content is read twice.
When the alert div contains a P block with the text, it is read once, after the word alert.
When the alert div contains a span block with the text, it is read twice, the same as if the text is entered directly.
The add multiple buttons are different tests for inserting multiple P blocks in the alert, and work as expected (since they are p blocks).

The problem I have here is that p blocks have semantic content, and have default CSS styling that affects how sighted users will see the alerts. This can be avoided with some CSS reset code, but it would be preferable to nest the text directly.

Comment 5 by Michael Curran <mick@... on 2014-04-16 01:07
In [19fd268]:

Reverting a change from December 2009 commit 6c53a29d where IAccessible NVDAObject's name property was forced to contain content from IAccessibleText if there was no caret present.

This was supposed to allow focusable labels in Thunderbird to read nicer. However, this caused a long-standing issue where the content of alerts in web browsers would speak twice, and Thunderbird now seems to oddly expose a caret on the labels thus disabling the code change anyway.
Removing this code may possibly cause some other regressions as its very old. However, if regressions are found they should be handled specificly for each case, as clearly this code was too general.

Should be a fix re #3481. May affect re #2442, #2745

Comment 6 by jteh on 2014-04-29 07:35
It looks like IE does fire alert events when a node loses display: none. It doesn't fire alert events for other cases. See this article for thorough coverage concerning this.

@jcsteh @michaelDCurran Just to clarify, is support for role=alert insufficient only in case of Internet Explorer, or does this affect other modern web browsers as well? If recent versions of Firefox and Chrome also demonstrate the problem(s) reported, then this ticket can be triaged, but addressing IE specific deficiencies are no longer worthwhile.

This only affects IE. NV Access is not going to actively pursue a fix, but will accept a PR.

You can fix it if you will add display=none before to add your alert node to DOM
Then when you added the alert node you need to add content to this node and set display=block
It works on IE and other browsers too

Support for Internet explorer ended completely in 2022, and the browser is being removed automatically from machines that still have it after an Edge update in February 2023. I don't expect any further accessibility updates to Internet Explorer or the IE mode in Microsoft Edge. Closing as abandoned.

As Mick commented above, this only affected Internet explorer as single application. If you can reproduce this issue with IE mode in MS Edge, please open a new issue with clear steps to reproduce.