Chrome and Opera speak words in alert twice when semantic elements like <strong> and <em> are included. #4066

nvaccessAuto · Apr 10, 2014

Reported by digitaltoast on 2014-04-10 10:51
Hello - first ticket here.

In Chrome, Opera and presumably other webkit-based browsers I've not tested yet, if an alert contains semantic tags such as or then it reads each section twice.

Exmaple:

<div role="alert"><p>The<em>emphasis</em>is on staying<strong>strong</strong>today</p></div>

Will read:

The The emphasis emphasis is on staying is on staying strong strong today today.

Notes:

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

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.

This is NOT the same as "reads entire alert text twice" which is a seperate ongoing issue for which several other longstanding tickets are still open.

I've googled and searched the bug tracker and haven't found anything yet related to this issue.

Is this a webkit issue that I should report to them, or an NVDA issue, bearing in mind it's only NVDA that exhibits this behaviour - as far as I know.

Example valid html without any other javascript, hacks, fiddles, workaround or other hocus-pocus to demonstrate the issue.

<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title></title> </head> <body dir="ltr"> <div role="alert"> <p>The<em>emphasis</em>is on staying<strong>strong</strong>today</p> </div> </body> </html>

This is currently also up at http://goo.gl/6FXRft but that's just a temporary testing ground so may not remain in the future.

Hope I've submitted my first ticket OK, thanks.

nvaccessAuto · Apr 10, 2014

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.

nvaccessAuto · Apr 10, 2014

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

nvaccessAuto · Apr 10, 2014

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?

nvaccessAuto · Apr 11, 2014

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

nvaccessAuto · Apr 11, 2014

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

for example then the alert is only read once.
[[BR]([BR]]
ticket:3481

)]

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?'''

nvaccessAuto · Apr 11, 2014

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".

nvaccessAuto · Apr 11, 2014

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>

nvaccessAuto · Apr 12, 2014

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.

nvaccessAuto · Apr 29, 2014

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.

nvaccessAuto · Apr 29, 2014

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

nvaccessAuto · Apr 29, 2014

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.

nvaccessAuto · May 26, 2014

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

nvaccessAuto · May 26, 2014

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

nvaccessAuto added the bug label Nov 10, 2015

nvaccessAuto added this to the 2014.3 milestone Nov 10, 2015

nvaccessAuto closed this Nov 10, 2015

tmorehouse referenced this issue May 21, 2019

Toast accessibility issue #3322

Closed

nvaccess/nvda

Chrome and Opera speak words in alert twice when semantic elements like <strong> and <em> are included. #4066

Chrome and Opera speak words in alert twice when semantic elements like <strong> and <em> are included. #4066

nvaccessAuto commented Apr 10, 2014

This comment has been minimized.

nvaccessAuto commented Apr 10, 2014

This comment has been minimized.

nvaccessAuto commented Apr 10, 2014

This comment has been minimized.

nvaccessAuto commented Apr 10, 2014

This comment has been minimized.

nvaccessAuto commented Apr 11, 2014

This comment has been minimized.

nvaccessAuto commented Apr 11, 2014

This comment has been minimized.

nvaccessAuto commented Apr 11, 2014

This comment has been minimized.

nvaccessAuto commented Apr 11, 2014

This comment has been minimized.

nvaccessAuto commented Apr 12, 2014

This comment has been minimized.

nvaccessAuto commented Apr 29, 2014

This comment has been minimized.

nvaccessAuto commented Apr 29, 2014

This comment has been minimized.

nvaccessAuto commented Apr 29, 2014

This comment has been minimized.

nvaccessAuto commented May 26, 2014

This comment has been minimized.

nvaccessAuto commented May 26, 2014

nvaccess/nvda

Join GitHub today

Chrome and Opera speak words in alert twice when semantic elements like <strong> and <em> are included. #4066

Comments

nvaccessAuto commented Apr 10, 2014

This comment has been minimized.

nvaccessAuto commented Apr 10, 2014

This comment has been minimized.

nvaccessAuto commented Apr 10, 2014

This comment has been minimized.

nvaccessAuto commented Apr 10, 2014

This comment has been minimized.

nvaccessAuto commented Apr 11, 2014

This comment has been minimized.

nvaccessAuto commented Apr 11, 2014

This comment has been minimized.

nvaccessAuto commented Apr 11, 2014

This comment has been minimized.

nvaccessAuto commented Apr 11, 2014

This comment has been minimized.

nvaccessAuto commented Apr 12, 2014

This comment has been minimized.

nvaccessAuto commented Apr 29, 2014

This comment has been minimized.

nvaccessAuto commented Apr 29, 2014

This comment has been minimized.

nvaccessAuto commented Apr 29, 2014

This comment has been minimized.

nvaccessAuto commented May 26, 2014

This comment has been minimized.

nvaccessAuto commented May 26, 2014