Nvda: Aria atomic seems to be ignored in Chrome

Created on 10 Mar 2020  路  13Comments  路  Source: nvaccess/nvda

Steps to reproduce:

Load the following markup in Chrome and append "Message 2" to the div's innerText with JavaScript:

```

Message 1

```

Actual behavior:

NVDA announces "Message 1 Message 2". _(all the content in the aria-live region)_

Expected behavior:

NVDA announces only "Message 2". _(the changed content in the aria-live region)_

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2019.3.1

Windows version:

Windows 10 Version 1909 Build 18363.657

Name and version of other software in use when reproducing the issue:

Chrome Version 80.0.3987.132 (Official Build) (64-bit)

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

Yes, Portable NVDA 2019.2. Same behavior

If addons are disabled, is your problem still occuring?

Yes

Did you try to run the COM registry fixing tool in NVDA menu / tools?

Yes

ARIA apchrome enhancement

All 13 comments

Duplicate of #8044

Duplicate of #8044

I think this bug is unrelated to #8044.

When we test it with Chrome 76 (July 2019), everything works. Only changed portions of ARIA live region get narrated. We download Chrome via https://chromium.cypress.io/.

But when we test it with Chrome 80 (March 2020), ARIA live region repeat the entire region.

While this is related to #8044 there is a key difference in the samples. This one specifies aria-atomic=false and appends some text. In #8044 aria-atomic=true is used, and the contents of the live region is replaced.

From: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions

aria-atomic: The aria-atomic=BOOLEAN is used to set whether or not the screen reader should always present the live region as a whole, even if only part of the region changes. The possible settings are: false or true. The default setting is false.

@SamRocK1030 Have you tested this sample with Firefox? It's quite helpful for us to know if the behavior differs.

@feerrenrut This sample behaves as expected in Firefox. I tested in version 74.0 and only the changed portions of the ARIA-live region get announced.

I get the same behavior with Google Chrome 80.0.3987.162 or Firefox 74.0 (64-bit) and the following sample:

<h2>Atomic=False live region</h2
<div>
    <div id="e2" aria-live="polite" aria-atomic="false">Old text</div>
</div>
<button onclick="document.getElementById('e2').innerText += '\n New Text'" >Append Text</button>

The speech from NVDA when pressing "append text" is "Old Text New Text"

@SamRocK1030 does my testing approach match what you intended?

@feerrenrut That approach matches the minimal test case that I had in mind.

Admittedly, the production code that I used to test in both browsers is more complicated (_Using react to update the DOM_).

I made the following codepen which exhibits the behavior I had originally seen in Chrome vs. Firefox:
https://codepen.io/SamrockAran/pen/mdJgVYL

I also see a difference between firefox and chrome with your codepen link. I can now replicate this without jquery now, the difference from the other sample in which I tried assigning innerText and innerHTML and this sample explicitly adding a child node. I guess this has to do with how the browsers keep track of the changes in an aria region.

<script>
    function appendDiv(insideId, text) {
        let el = document.getElementById(insideId)
        let newDiv = el.appendChild(document.createElement('div'));
        let textnode = document.createTextNode(text);
        newDiv.appendChild(textnode);
        el.appendChild(newDiv);
    }
</script>

<h2>Atomic=False live region</h2
<div>
    <div id="e2" aria-live="polite" aria-atomic="false">
        <div>Old text</div>
    </div>
</div>
<button onclick="appendDiv('e2','New Text')"
    >Append Text</button>

See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1067257
https://bugs.chromium.org/p/chromium/issues/detail?id=863375#c29

I'm able to reproduce in Chrome 83. Using role="log" aria-atomic="false" aria-live="polite".

Behaves as expected in Firefox 76.

This issue was addressed in https://crbug.com/910669.

@ObjectInSpace does it mean it will land in Chrome 84?

According to the crbug it has been tested in canary 85.0.4164.0

I have confirmed this works as expected with NVDA and Chrome canary 85.0.4169.1

I think we can close the issue now.

Was this page helpful?
0 / 5 - 0 ratings