[Accessibility][Screen Readers][bot name - Test in Web Chat]: Screen reader is not providing the descriptive information when focus is on "New Messages" button.

[ShikhaMishra11]

Original: microsoft/BotFramework-Emulator#1978

User Impact:
Users who depends on screen reader will get confuse if screen reader is not providing the descriptive information when focus is on "New Messages" button.

Test Environment:
OS: Version: 1903(OS Build 18956.1000)
URL: https://ms.portal.azure.com/#@microsoft.onmicrosoft.com/resource/subscriptions/8d5ceb22-44c7-4367-bfc6-07378096e055/resourceGroups/sddsddd/providers/Microsoft.BotService/botServices/avinash/channels
Browser: Edge
Screen Reader: Narrator

Pre requisite:
create new web app bot.

Repro Steps:

1. Turn on Narrator.
2. Open https://ms.portal.azure.com/#@microsoft.onmicrosoft.com/resource/subscriptions/8d5ceb22-44c7-4367-bfc6-07378096e055/resourceGroups/sddsddd/providers/Microsoft.BotService/botServices/avinash/channels in Edge.
3. Navigate to already created web app bot.
4. Navigate to "Test in Web Chat" element and activate it.
5. Now "Test" screen will be displayed.
6. Navigate to "New Messages" button and verify whether screen reader is providing the descriptive information when focus is on "New Messages" button.

Actual Result:
Screen reader is not providing the descriptive information when focus is on "New Messages" button.
Screen reader is reading as "New Messages button"

Expected Result:
Screen reader should provide the descriptive information ,when focus is on "New Messages" button.
Screen reader should read as "New Messages button, hit ENTER to see the new messages".

Note:
Same issue repro with NVDA also.

MAS Reference
https://microsoft.sharepoint.com/:w:/r/teams/msenable/_layouts/15/WopiFrame2.aspx?sourcedoc=%7B54f28d1f-a2d1-4dcd-84e1-5c9b87e8aba4%7D&cid=ea080456-8c71-4c66-b1f0-9a2a20e08097

Attachment:
New Messages button descriptive.zip

[corinagum]

I am considering using an access key to accommodate this a11y deficiency. I will summarize in bullets to be as concise as possible:

• Access keys allow for focusing on specified DOM elements.
• An example string that the screenreader would announce would be: "There are new messages available. Press Alt + f to respond."
• This is cross-browser and cross-OS compatible by detecting both and then altering the text directions of what keys to press. See screencap below:

• We will need to make the access key 'style-able' using defaultStyleOptions. I'm thinking the default accesskey could be 'f' for focus, but if the dev wants to change it they would be able to do so.
• I believe this would work with accessibility by using multiple strings to identify the full key combination according to browser, OS, and accesskey (regardless of using default or customized key).
  • However, I would like to discuss this either with @compulim or the Localization team since I am not as familiar with the difficulties of combining multiple variables. Looking at the new en-US.json, I think this would be possible.

As a note, there is currently a related problem on Edge regarding using arrows to navigate up and down the DOM. I have started this discussion on an issue in the Emulator repo. I'll update as discussion continues.

Current action items for me:

• Test the combination of AT and access keys to see if there are conflicting commands or usages
• Look into accesskeys with React
• Look into whether or not this should be aria-live=polite or not

[compulim]

Also, please contact localization team as they have concern on using accesskey attribute.

[Amit8527510735]

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