Web Chat as a widget should remember last focused element

[corinagum]

Feature Request

If user leaves the chat, the focus is lost. Re-entry of the Chat moves focus to the top of the UI. Only the items present in the viewport from the start position of the chart are available to the screen reader. The must user arrow down to hear elements but will not be able to see the what question they’re answering

When Web Chat developers use Web Chat in a widget capacity, moving focus outside of the widget then back inside the widget does not remember the last focused element in Web Chat.

The feature request is to:

1. Store last focused element by making it tab index 0, so that returning focus to Web Chat widget immediately jumps to last focused item
   • Question: Can you set tabindex in a widget, so it doesn't affect tab order within the main app?
   • Question: Isn't this taking for granted that a user will immediately want to tab back to last focused element in WC?
   • Doesn't resolve issue of (potentially) having to traverse entire DOM to get to WC widget

and/or

1. Create an accesskey that allows the user to jump back to last focused element (similar to accesskey for focusing on the send box proposal [Accessibility][Screen Readers][bot name - Test in Web Chat]: Screen reader is not providing the descriptive information when focus is on "New Messages" button. #2669 (comment))

Describe the suggestion or request in detail
Example scenario:

• User focuses on button inside transcript (inside Web Chat widget)
• User interacts with combobox within the main app (outside Web Chat widget)
• User should be able to re-focus to previous button inside the transcript

Describe alternatives you have considered

• aria-activedescendant

Additional context
Original discussion at: #3533 (third bullet)

[Enhancement]

Please thumbsup this comment if this is a feature you are looking for.

[compulim]

According to MDN, tabindex="0" means:

tabindex="0" means that the element should be focusable in sequential keyboard navigation, after any positive tabindex values and its order is defined by the document's source order.

It will not surface that element as the "first focusable element" when the user TAB into Web Chat widget.

As I mentioned during our offline discussion last week:

• I would ask the accessibility team: I see nav bar share commonality with Web Chat as an UI landmark. How TAB works on nav bar?
• We could use a focus-listening element to capture the first focus and send the focus to the element
  • When the root container of our UI is blurred:
    • Remember the focusing element
    • Add a hidden TAB-able element as the first element in our UI (a.k.a. sentinel or similar words)
  • When the sentinel get focused:
    • We send it back to the focusing element
  • When any part of our UI get focused:
    • Remove the sentinel

Remembering the focusing element is not trivial, it could be something inside Adaptive Cards (outside of React, requires DOM manipulation), or it could be something that is already re-rendered (DOM node no longer valid).

[corinagum]

Thanks, yeah a11y team says it's easier than it sounds, but I have my doubts. This list helps. We should set up another meeting with them.

[Amit8527510735]

Could you please provide us proper repro steps and control details to verify the issue, because we are unable to locate the exact screen and issue.

[corinagum]

@Amit8527510735 I'm waiting for customer feedback on the exact repro scenario, but I will post more details as soon as I hear back from them.

[corinagum]

Been trying to track down customer engagement, but I haven't been able to do so. Closing this issue.