Comment 1 by digitaltoast on 2014-04-10 11:00
Sorry, I've not worked out how to edit tickets yet, but correction:
When I said webkit I meant blink of course as both of these browsers now use this webkit fork.

For complete clarity, IE and Firefox do NOT exhibit this behaviour, which is why I was guessing that it might affect all Blink browsers as it affects both Chrome and Opera which are both Blink based. As far as I know.

Comment 3 by vgjh2005 on 2014-04-10 13:48
If you use the profile to adjust the voice speed.

Comment 4 by digitaltoast on 2014-04-10 13:55
Hi vgjh2005 - I think you are asking if it does the same if I adjust the voice speed.

I can confirm that the behaviour is the same whether I speed the voice up or slow it down, whether I use the built in espeak, Microsoft synthesizer or an external synth.

I even completely reset my preferences to factory default and restarted. It still does it.

Are you saying that you have experienced this, but only with a different voice rate?

Comment 5 by jteh (in reply to comment description) on 2014-04-11 00:40
Thanks for the report.

Confirmed. I think this is because Chrome-based browsers expose the content as both the name and the text of the object. Arguably, they shouldn't expose it in two places, but it probably isn't unreasonable for us to check for duplicates in this case.

Replying to some specific points:
Replying to digitaltoast:

• The P inside the div is the NVDA-suggested workaround for IE not reading the alert at all.

I don't recall this suggested work around, nor do I see how it would help. Of course, it's highly possible I've forgotten something. :) Can you point me at this discussion?

• It doesn't matter how I inject it, what I wrap it in, how I add or change the alert, or which of the 4 current workarounds for alerts not speaking I use, it always behaves like this.

aria-describedby would probably work, as this explicitly specifies the alert content and thus overrides NVDA's calculation, but this obviously shouldn't be necessary.
Changes:
Milestone changed from None to next

Comment 6 by digitaltoast on 2014-04-11 07:00
Thanks @jteh.

The P inside the div is the NVDA-suggested workaround for IE not reading the alert at all.

I don't recall this suggested work around.

[apologies - you're right, I've got so many notes from the last few days I've got all muddled; it was actually cottrell in ticket:3481#comment:1 who said:
[[BR]([BR]]
Many)]

It appears to be a problem when a div contains text directly. If the text is wrap using a

for example then the alert is only read once.

[in fact, entirely the opposite. Having worked my way through various tests, it seems that if I can make it alert once in Firefox it won't speak in IE, but using any workaround to make IE speak the alerts makes it alert twice in Firefox.

I think the following tickets might be relevant:

ticket:2442

"When I use NVDA, I'm getting the dynamically-added content is being read -twice- by the reader in Firefox

[[BR]([BR]]
So)]
last entry is 12 months ago when he says
["I'm still seeing the dynamically generated text being read twice in Firefox 20.0.1"
[[BR]([BR]]

)]

ticket:2745

It also looks like if you swap out the DIV for a span it will work. However, if your span has either position:fixed or display:block it will stop working.

[It appears to be a problem when a div contains text directly. If the text is wrap using a

)]

Also c8f02f472d4182fadfb1eb3304859b315fb8c5a6 may be relevant.Says it fixes http://community.nvda-project.org/ticket/248 from 5 years ago any workaround I use to get alerts to work in IE11 brings this doublespeaking back.

The following may also be of interest:
http://blog.paciellogroup.com/2012/06/html5-accessibility-chops-aria-rolealert-browser-support/
http://accessibleculture.org/articles/2011/02/aria-alert/
http://lists.nvaccess.org/pipermail/nvda-support/2012-June/007447.html

== tl;dr: ==
'''Is there a reliable method of getting NVDA to speak alerts in a timely manner without hesitation, repitition or deviation, at least across current versions of Firefox and IE, preferably without the word "alert", which is also compatible with other aria-live aware screen readers?'''

Comment 7 by jteh (in reply to comment 6) on 2014-04-11 11:53
Replying to digitaltoast:

So in fact, entirely the opposite. Having worked my way through various tests, it seems that if I can make it alert once in Firefox it won't speak in IE, but using any workaround to make IE speak the alerts makes it alert twice in Firefox.

I don't follow what you mean by a workaround to make IE speak the alerts. NVDA simply doesn't support alerts in IE (#2442). Unless you know of some trick I don't, it just won't work no matter what you do.

'''Is there a reliable method of getting NVDA to speak alerts in a timely manner without hesitation, repitition or deviation, at least across current versions of Firefox and IE, preferably without the word "alert", which is also compatible with other aria-live aware screen readers?'''

Unfortunately, getting this right is a lot more complicated than it seems. NVDA treats alerts similarly to dialogs because browsers and other applications often use alerts for dialog-like content that doesn't get the focus. They aren't the same as normal live regions because there are different rules as to when they should be reported and what to report. I don't follow the request to remove the word "alert"; it is an "alert" after all. If you don't want it to be an alert, don't use role="alert".

Comment 8 by digitaltoast on 2014-04-11 12:09

I don't follow what you mean by a workaround to make IE speak the alerts. NVDA simply doesn't support alerts in IE (#2442). Unless you know of some trick I don't, it just won't work no matter what you do.

Sorry, my ticket reply was quite long so the detail might have been lost in the waffle!

Specifically, it's using method three from this page - http://blog.paciellogroup.com/2012/06/html5-accessibility-chops-aria-rolealert-browser-support/

It certainly fires it off as an alert in IE11 on Windows 8, but says (for, say, "hello")
"hello alert hello". Note the comment in the code about aria-atomic being required too.

TBH, in a worse case scenario, I can live with an alert being read twice over no alert at all in a different browser. I realise I'm wandering off the original ticket bug. Would you like me to open a new separate ticket for this IE vs Firefox issue?

Here's my playground page (https://googledrive.com/host/0B2NJeY_BTHQfaV9sY2wwRm55UEU/testalert.html which may vanish at any time), but I've also pasted the code below.

<!DOCTYPE html>
<html lang="en">

<head>
    <title>ARIA alert fix by Changing CSS display:none to inline</title>
    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js"></script>

    <script>
        function displayAlert() {
            $('.alertMessage').css({
                "display": "block"
            }).html("<p class=\"alert\"><p>The <em>emphasis</em> is on staying <strong>strong</strong> today</p>");
            setTimeout(function() {
                $('.alertMessage').css("display", "none");
                $('.alert').remove();
            }, 1500);
        }
    </script>
    <style>
        #alertMessage {
            display: none
        }
    </style>
</head>

<body dir="ltr">
    <h1>ARIA browser testing page</h1>

    <div role="main">
        <section aria-label="alert testing section">
            <h2>Alerts</h2>
            <p>
                <a href="#" tabindex="0" onClick="displayAlert()">Alert fired using href="#" onClick="displayAlert()</a>
                <br />
                <a href="javascript:displayAlert();">Alert fired using href="javascript:displayAlert();"</a>
                <br />
                <button type="button" onclick="displayAlert();">Alert fired using button type="button" onclick="displayAlert();"</button>
                <br />
            </p>

            <!-- aria-atomic from http://pauljadam.com/demos/aria-alert-validation.html -->
            <div class="alertMessage" role="alert" aria-atomic="true" aria-live="assertive" style="display: none">
                <p></p>
            </div>
        </section>
    </div>
    <footer>End of page</footer>
</body>

</html>

Comment 9 by jteh on 2014-04-12 01:44
Interesting. This suggests a more recent version of IE started firing the alert event correctly, at least some of the time. If I recall correctly, it never used to fire it at all.

I think the bigger priority is addressing the mangled speaking as originally described in this ticket. Repeated speaking is annoying and still needs to be addressed, but is lower priority.

Comment 10 by James Teh <jamie@... on 2014-04-29 08:14
In [aa29b53]:

In Google Chrome and Chrome-based browsers, certain chunks of text (such as those with emphasis) are no longer repeated when reporting the text of an alert or dialog.

This occurred because getDialogText uses text leaf nodes, but text leaf nodes in Chrome include their text in both accName and IAccessibleText.
getDialogText now assumes the name is always part of the text for static text objects.
Re #4066.

Comment 11 by James Teh <jamie@... on 2014-04-29 08:15
In [81f2182]:

Merge branch 't4066' into next

Incubates #4066.

Changes:
Added labels: incubating

Comment 12 by jteh on 2014-04-29 08:16
Note that this change depends on the fix for GoogleIssue:chromium:328261. This is fixed in Chrome Canary. If I'm not mistaken, I think it'll be in Chrome 35.

Comment 13 by James Teh <jamie@... on 2014-05-26 06:09
In [2c85af1]:

In Google Chrome and Chrome-based browsers, certain chunks of text (such as those with emphasis) are no longer repeated when reporting the text of an alert or dialog.

This occurred because getDialogText uses text leaf nodes, but text leaf nodes in Chrome include their text in both accName and IAccessibleText.
getDialogText now assumes the name is always part of the text for static text objects.
Fixes #4066.

Changes:
Removed labels: incubating
State: closed

Comment 14 by jteh on 2014-05-26 06:22
Changes:
Milestone changed from next to 2014.3