1249222 - ARIA live example broken on whatsock

Status: RESOLVED INVALID

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

Received this report from Bryan Garaventa. He reported that the following steps work in Firefox 43, but are broken in 44, and I've verified that this is still broken in 47.

0. Use NVDA on Windows with Firefox 44 or Nightly.
1. Open http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20%28Native%20Inputs,%20Editable%20and%20Readonly%29/demo.htm
2. Tab to the State Or Province combobox.
3. Type the letter c.

Expected: NVDA should speak "California", which is pushed to the end of the document into a div with aria-live="polite".

Actual: Nothing is spoken. I've also verified that the insertion of the ARIA live region is not reflected in the accessibility tree. So the DIV gets inserted, but not in the accessibility tree. This is not a problem of an event not firing, the div is not there at all.

5. Type o.

Result: Now, the live region appears and speaks the state "Colorado".

6. Press backspace to delete the o.

Result: Now, "California" is spoken.

7. Delete the c by pressing BackSpace.
8. Type the c again.

Result: Same as above, live region is not inserted and does not fire.

Alex, any ideas?

Comment 1

[Marco Zehe (:MarcoZ)]

In trying to investigate the exact build this regressed, I found that I cannot find any "good" build, even going back to Firefox 41. Trying to verify, I also found that the example doesn't work in Chrome, either. e. g. the live region only fires after the second letter is entered there, too. I sometimes even don't get the list of states if only typing c and pressing down arrow.

Bryan, are you sure your example is still working as intended? From this end, it looks like this isn't our bug after all...

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

Removing regression keyword based on comment 1

Comment 3

[Marco Zehe (:MarcoZ)]

This is still a problem in Nightly 63. Jamie, do you have any idea here?

Comment 4

[James Teh [:Jamie]]

TL;DR: This test case has some bugs, but it also relies on some questionable assumptions. Certainly, this is not our bug.

There are a few things going on here:

(In reply to Marco Zehe (:MarcoZ) from comment #0)
> 3. Type the letter c.
> Expected: NVDA should speak "California", which is pushed to the end of the
> document into a div with aria-live="polite".
> Actual: Nothing is spoken. I've also verified that the insertion of the ARIA
> live region is not reflected in the accessibility tree. So the DIV gets
> inserted, but not in the accessibility tree. This is not a problem of an
> event not firing, the div is not there at all.

I'm not sure about when this was filed, but I definitely see the div now. When the document first loads, the document accessible has two children: a header and a text frame. After typing "c", there is a third child: a section. That's our live region.

This is where the questionable assumption comes in. I'm not sure about other screen readers, but NVDA won't report a live region when it is first added to the document. It only gets reported if content is added *after* it was added. The reason is that otherwise, the user might be flooded with content when a page first loads, since on the modern web, we have no way of knowing when a document has truly finished "loading". There is some support for this behaviour in the spec, since the spec talks in terms of "updates" to live regions. This is not an "update"; the live region didn't exist in the first place.

> 7. Delete the c by pressing BackSpace.
> 8. Type the c again.
> Result: Same as above, live region is not inserted and does not fire.

Once the live region is first added, it never disappears. You'll always see that third "section" child of the body.

This is where we hit a bug in the test case. When you type "c" into the empty text box again, the live region is *not* updated. Testing this is really tricky because the live region content is removed within a second. I confirmed this bug as follows:
1. Open the web console with control+shift+k.
2. Enter the following code:
setTimeout(function() {alert(document.querySelector("[aria-live]").innerHTML);}, 5000);
3. Switch back to the document, then type "c" into the combo box such that you type the "c" after 4.5 seconds has elapsed since you pressed enter in the console.
expected: The alert which appears half a second later should say "California".
Actual: It says nothing.
4. Repeat steps 1 and 2.
5. Switch back to the document, then type "o" into the combo box such that you type the "o" after 4.5 seconds has elapsed since you pressed enter in the console.
Result: As expected, the alert that appears will say "Colorado".

Also, we see the same results in Chrome.

Closing as invalid.

Comment 5

[Bryan Garaventa]

Thanks for looking into this. Actually the same technique is used here within this live chat demo, and it does fire the correct events, so I think things are working properly.
http://whatsock.com/tsg/Coding%20Arena/Web%20Chat%20and%20Dynamic%20Message%20Announcement/Web%20Chat%20(Static)/demo.htm

The live region is not rendered onLoad, but only on the first use of this feature. However, the string is not added at the same time as this rendering, but directly after the empty live region container is added to the DOM. Afterwhich, the string message is inserted within the container using element.innerHTML to trigger the event. Since live regions don't work when hidden, an offscreen class is used instead, and messages are cleared automatically after they are loaded within approximately 1 second to ensure that users don't encounter this content at the end of the page during regular navigation. As with the chat demo, multiple messages that are sent at or about the same time are automatically queued and sent to this live region to allow for all incoming messages to be announced without loss of data or borking API events if triggered too quickly in succession.

Hopefully this helps explain the background logic a bit.