Vispero: Add role="log" to bot framework messages so JAWS users don't need to switch modes

[Amit8527510735]

Accessibility 161417: Vispero: Add role="log" to bot framework messages so JAWS users don't need to switch modes

Product name, version: Azure Bot Framework, Edge/Chrome v.88

OS version and build: Windows 10 19042.572

Bot Framework Version: 4.11

AT version and build (if applicable): JAWS 2020

Does this repro with other AT? (If applicable): No

Share access to the environment (if applicable): React App (https://microsoft.github.io/BotFramework-WebChat/06.recomposing-ui/d.plain-ui/)

Prerequisite (if any): N/A

Description:
In the Azure Bot framework, messages are read out automatically with ARIA live alerts. In the case of JAWS, users still may need to toggle modes – virtual PC cursor on/off. We reached out to JAWS, and they indicated that the incoming messages should have role=”log” so JAWS reads them automatically without users needing to switch modes.

Repro steps

1. Enable JAWS
2. Open sample URL
3. In Chat field, type “image” and press enter
4. Observe messages come in (in this sample they won’t be read automatically)

Screenshots: N/A

Actual results
When new messages appear and are read out, users may still need to navigate through the conversation history to read them. To do this today, users have to manually toggle modes in JAWS with Insert+Z. According to Vispero, adding role=”log” would avoid this issue.

Expected behavior: users can read messages without switching modes in JAWS

Note: Comment from Vispero developers:
As an enhancement to the bot's performance with JAWS, you may find it helpful to put a role="log" attribute on the div which contains the bot's responses. Doing this will allow JAWS to speak the new responses without the need to exit forms mode and read them. This should be helpful even when the bug is fixed, since it will allow the user to simply type and listen more interactively.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships

[Amit8527510735]

#Accessibility;#WCAG1.3.1;#HCL;#HCL_BotFramework_WebChat;#A11yMAS;#A11ySev2;#Closed;

[corinagum]

The plain-ui sample is for demo purposes only and not intended to be accessible, or to be used as a final iteration for an app. For accessibility in custom components (such as this), the onus is on the developer to ensure their entire app is a11y compliant. If your issue is in regards to this sample specifically, this problem is a no-op.

Are you saying the requirement to switch modes is occurring in our getting started sample? https://github.com/microsoft/BotFramework-WebChat/tree/master/samples/01.getting-started/a.full-bundle Please confirm.

If such is the case, this will need to be discussed with @compulim, who is unavailable for the next few weeks.

@cwhitten FYI.

[mrivera-ms]

This will addressed in the R12 release.

[Amit8527510735]

@compulim : We have given you a sample application link(https://microsoft.github.io/BotFramework-WebChat/06.recomposing-ui/d.plain-ui/) to repro the issue. But issue also exists on Bot framework chat window.

[corinagum]

I spoke with @compulim about this last week. The reason we are unable to assign role="log" to the Accessibility transcript (<ScreenReaderText>) is due to aria-live="polite" being the value for elements with role of log.

However, role="log" is assigned to BasicTranscript.js:

If we were to set log to <ScreenReaderText>, every incoming activity would be read twice; once from the transcript, and once from the screenreader text.

This new system is explained a bit more at the original PR: #3548
Essentially, <ScreenReaderText> is necessary to ensure that an incoming activity including the attachment is read out in an accessible way by AT. This solution was recommended to us from the C+AI accessibility team, and therefore making changes to this will need more discussion.

Accessibility is one of our highest priorities on the Web Chat team, and we want to ensure the best experience possible. The team will need to further discuss solutions to this problem. I will continue to report back here as more details are scoped out.

[amal-khalaf]

I tried repro`ing the described issue using JAWS and https://github.com/microsoft/BotFramework-WebChat/tree/master/samples/01.getting-started/a.full-bundle
but i see that screen reader announce the incoming activity image properly.

jaws-ann-image-2021.01.13-12_48_07.mp4

[Amit8527510735]

Now JAWS is announcing incoming activity image properly. Hence closing the bug.