Screen readers narrate all the messages from the beginning for every new message

[maggi1129]

Screen readers narrate all the messages from the beginning for every new message

[corinagum]

I'm only reproing this on Edge with Narrator. NVDA reads only the most recent changes. If I recall correctly, this is an improvement that can be made on the Narrator app, not Web Chat. Do other team members have input?

[corinagum]

I have been investigating this and have some results to share. First, please see my repro steps:

1. Navigate to full bundle in Firefox, Edge, Chrome, IE, or Safari (For IE: use es5 bundle)
2. Turn on Narrator, VoiceOver, or NVDA
3. Type “Hi” in the send box and send
4. Observe screen reader behavior
5. Type “timestamp” in the send box and send
6. Observe screen reader behavior

Notes on the results for each pairing are below: (blank means not tested)

	Chrome	Edge	Firefox	IE	Safari
Narrator	No updates from transcript	Reads each activity twice, possibly because of send status change from just now to 1 minute ago?	No updates from transcript	No updates from transcript
NVDA	Voice speaks transcript updates	No updates from transcript	Voice speaks transcript updates	Voice speaks transcript updates
VoiceOver	Voice speaks transcript from beginning whenever there is a new activity		Voice only speaks VoiceOver recommendations; does not recite transcript		Voice speaks transcript, but interferes with VoiceOver suggestions. Implies that aria-live is set to assertive

Some notes:

1. Previously, Web Chat was implemented with aria-label to read each activity with the following information: who said the activity (Bot or User), the activity text, and the timestamp (which would usually be 'Just now'). This drove me crazy, and I have removed the timestamp readout from our logic so that the screen reader, if working ideally, will say "User said, hi" instead of "User said, hi, just now". This will be included in my eventual PR.
2. In an attempt to get these scenarios to function more uniformly, I am going to be explicit with the aria-live attributes instead of depending on the default values. In particular, aria-atomic's default value is supposed to be false, and aria-relevant should be be all, but instead I will be explicit in the hopes that this improves browser compatibility. I will post these new results on this issue, probably tomorrow.
3. ARIA support across browsers is really spotty. I personally want to provide an app that's accessible to people of all abilities, but with WAI-ARIA is not fully supported by any browser, and I am unsure the depth at which we are able to tackle this without first getting browser compatibility. My next step will be to consult with our team's Accessibility team and see if they have advice for improvements on our app. Included in this will be a simplified version of our DOM to show where are aria-live attributes are being inserted.
4. I haven't been able to find anything online about aria-live regions interfering with each other. As a last resort I will test if the screen reader functions more ideally if there's only one aria-live region being tracked. Right now I believe we have two: the transcript and the send status.

More information to come!

[corinagum]

I made a basic app to test aria-live features: ARIA-screenreader-testing

This app previously had two (nested) aria-live features to mimic Web Chat. Unfortunately this caused problems in Firefox where the nested live region was always read twice. Because of this, I will be removing the nested live region in Web Chat to improve compatibility across browsers.

Description of App
This app has an unordered list that makes up the live region, with two separately updating features:

1. The list starts with two items but will regularly add another <li> to the list with a random number as text.
2. The last bullet will regularly update the time in milliseconds since the page was refreshed.

Expected Behavior

• All screen readers should read the entire list on first run-through
• Subsequent changes to the list (additions and change of text) should be read, but the entire list should NOT be repeated.

Results

	Chrome	Edge	Chromium Edge	Firefox	Safari
Narrator	✔️	Doesn't respect aria-live="polite", but reads both updates	✔️	Doesn't read live regions, with or without 2 live regions
NVDA	✔️	Only reads text updates of the time interval; it ignores random number pushes, even with only one live region	✔️	Reads the time live region twice unless I remove the 'redundant' aria-live attributes in the list item. ✔️
VoiceOver	aria-atomic="false" doesn't work; aria-live="polite" doesn't work			✔️	✔️

Notes

• I had to update Safari to version 12.1.1 to get VoiceOver to work on Mac
• Because of FireFox with NVDA, Web Chat will have the second live region attributes removed
• It seems that a11y compatibility on Edge is broken, but Chromium Edge works
• We will only ensure that Safari and VoiceOver work together; VoiceOver isn't guaranteed to work on other browsers
• I think a good baseline expectation for screen reader compatibility with Web Chat should be thus:
  On Mac: Safari and VoiceOver
  On Windows: Chrome and Chromium Edge should work with Narrator and NVDA

Changes to be made on Web Chat

• Explicitly designate the aria-atomic and aria-relevant attributes
• Remove nested live region attributes
• Remove "xMinutesAgo" from the "User sent __" and "Bot sent __" aria-label strings
• Change aria-label of the <SendStatus> component to be an absolute timestamp for the "xMinutesAgo" feature, but remain as "Sending" before send has completed. This will presumably prevent the screen reader from repeatedly updating all <SendStatus>es in the transcript.
• A chart confirming which browsers and what screen reader we expect Web Chat to work on.

PR with the above changes to come, hopefully today!