[Accessibility] Update activity timestamp grouping to match visual UI

[corinagum]

(Filed internally from Web Chat customer)

Currently, AT will read every date/time after each activity, regardless of grouptimestamp style option

Version

4.11.0

Description

• Currently on AT, each activity is read with the accompanying timestamp, regardless of the visual UI.
• By default, the visual UI groups all uninterrupted activities from a single user with one timestamp.

Request:

• Modify behavior to match visual UI
• Note: this change will regroup incoming activities to be grouped with a single timestamp for AT. This will fix behavior when navigating the DOM tree. Expected behavior when navigating the DOM (iPhone: single-finger-right-swipe): each paragraph and activity is read separately, but there will be only one timestamp at the end of one group. In this case one group amounts to all uninterrupted activities from a single user.
• However, during live reading, each incoming activity will always be accompanied by a timestamp and therefore may be read by VoiceOver before the next activity arrives and the regrouping is performed. Web Chat already has message rendering delays to avoid too many screenreader repeats due to these re-renders, but we can’t guarantee this change will prevent the date being read live before a new activity is rendered.
• Regrouping should also be applied to 'Bot said', 'Bot attached' text

[corinagum]

Currently being investigated by compuilim

[amal-khalaf]

Investigation Results:
once activity is marked as sent it is written to DOM as well as it Timestamp , only when the next activity arrive and mark as sent when the group timestamp logic kicks in. which could be milliseconds apart.
the technical limitation here is once a live region element is written to the DOM and marked with aria attribute to be logged
it is added to narration queue so even if we removed the element from the DOM later on it will still be announced.

Actions:
I discussed the issue and above limitation with Guy Barker and Ryan from accessibility team their input on this issue is the following:

• given that the case here is a user getting more information not losing or hiding any ,
• the recommendation is to add documentation that live activity will always have time stamp associated to them
• this issue severity could be lowered and closed.

[corinagum]

@amal-khalaf I mentioned in the email I sent that this will be closed, but would you prefer to make this P1 P2 and add that documentation for R12?

[cwhitten]

● useScrollTo.keepNewMessagesButton › should scroll and keep "New Messages" button

Unhandled exception from the test code on the page.

Error: Test code timed out while waiting for "New message button is shown".

  at http:/webchat2/__dist__/testharness.js:1:5036
  at _loop$ (__tests__/html/__jest__/createJobObservable.js:47:13)
  at tryCatch (node_modules/regenerator-runtime/runtime.js:63:40)
  at Generator.invoke [as _invoke] (node_modules/regenerator-runtime/runtime.js:293:22)
  at Generator.next (node_modules/regenerator-runtime/runtime.js:118:21)
  at tryCatch (node_modules/regenerator-runtime/runtime.js:63:40)
  at maybeInvokeDelegate (node_modules/regenerator-runtime/runtime.js:356:18)
  at Generator.invoke [as _invoke] (node_modules/regenerator-runtime/runtime.js:267:32)
  at Generator.next (node_modules/regenerator-runtime/runtime.js:118:21)
  at asyncGeneratorStep (node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:24)

[corinagum]

Closing as complete