Confusing keyboard navigation experience

[botkid25]

Version

Version 4.12.1 via npm

Describe the bug

To navigate through the messages within the transcript using the keyboard, the user needs to use tabbing, enter, and arrow keys. A bug was filed against us because you cannot get to the messages by tabbing alone, which was found to be confusing. This keyboard navigation experience appears to be working as expected: https://github.com/microsoft/BotFramework-WebChat/blob/main/docs/ACCESSIBILITY.md. Is there any public document besides this Github accessibility link that we could reference from our bot to make the experience less confusing, like a user's accessibility guide?

Expected behavior

User should be able to easily navigate with the keyboard to any of the focusable or tabbable elements without confusion.

Additional context

@cwhitten

[hcyang]

Hi @cwhitten and @botkid25, how did the work-item 43767 (which, understandably, I don't have access to) show up in this externally raised github issue?

[compulim]

@botkid25 We consult with internal accessibility team to come up with this focus type.

In WAI-ARAI guideline, there are two types of navigation focus. You can read more about them at the "Managing Focus" section from this article. In short:

• Single focus. User uses TAB key to access them
• Focus with active descendant. User uses TAB key to focus and arrow keys for "sub-focus" (a.k.a. active descendant)
  • Used by many widgets, such as auto complete box, combo box, dropdown, grid, etc.
  • Allow user to put the focus on one element, and navigating inside that element for another "sub-focus"
  • In our case, the user focus on transcript, then navigate inside for message

Unlike other chat UI which is primarily text and does not contains multiple interactive elements (non-composite widget). In Web Chat, bot could send a card which contains tappable buttons (composite widget). The single focus approach could create a lot of confusion to users who use screen reader.

Let me play a story around the "single focus" approach.

Assume the last message from the bot is a card asking the user "Do you agree?" with a "Yes" button followed by a "No" button. When the screen reader user press SHIFT + TAB to navigate from the send box to the last message. They would immediately jump to the "No" button. The screen reader may only say "No, button". Screen reader may not announce "Do you agree?" This would create confusion for the user.

On the other hand, for the "active descendant" approach.

After user press SHIFT + TAB to navigate to the last message, the active descendant would land on the last message, instead of "No" button. The screen reader would say "Bot said, do you agree? Press ENTER to interact." The user can know about the context of the message before interacting with it.

Another confusion point, which is a technical limitations in today's browser is the "End of transcript" block (a.k.a. terminator).

We would love to eliminate the terminator to reduce another SHIFT + TAB. But unfortunately, modern browsers are slow at adding the new inert attribute. You can read more about it here.

There are 2 articles from W3C that talks about UX for widgets, you can read more about different widget roles and their requirements:

• Accessible Rich Internet Applications (WAI-ARIA) 1.1
• WAI-ARIA Authoring Practices 1.1

AFAIK, the most complex widget mentioned in the articles is the grid widget. Since chat UI could contains subcomponent, it is more complex than grid. Currently, there are no recommendations yet. Once it become available, we will adopt the W3C standard to create a more uniform UI for everyone.

Thanks.

[botkid25]

Thanks @compulim for that explanation and for the references!

I think the major reason this bug was written was because the tester was not using the screen reader, so without the auditory instructions to press enter to interact, the tester didn't know that was an option. But based on your references, am I correct in thinking that this composite widget approach is well-known enough that users who rely on keyboard navigation (and not a screen reader at the same time) would know they have this option? Or do you think we could benefit from linking to one of these pages, such as the one on Managing Focus, for users who may be new to keyboard navigation?

[botkid25]

@compulim in a similar vein with this confusing keyboard navigation experience, it appears that tabbing forward and tabbing backward produces different results.

Repro steps:

1. Navigate to https://microsoft.github.io/BotFramework-WebChat/01.getting-started/a.full-bundle/
2. Send message to bot, e.g., card containerstyles
3. Tab forward through page until focus is on transcript - notice how no activity gets focus
4. Tab forward to End of Transcript, then Shift + Tab back to transcript - notice how last activity gets focus

I see in the BasicActivity.js file, there's a callback to setBottommostFocusedActivityKeyIfNeeded. Is there any way that the bottommost activity could receive focus on the forward Tab through the page as well?

[compulim]

Thanks @botkid25. This is a great catch!

Let me slightly update your repro steps for clarity:

1. Navigate to https://microsoft.github.io/BotFramework-WebChat/01.getting-started/a.full-bundle/
2. Send message to bot, e.g., card containerstyles
3. While focus is on the send box (default), press TAB until the focus is looped through and land on the send box again
   • Notice that active descendant (dashed focus) was not set on any activities
   • Even the transcript is focused after a single TAB from the address bar, no activity become active descendant
4. After the focus landed on the send box again, press SHIFT + TAB 3 times
   • Notice that active descendant was SET on the bottommost activity (dashed focus on the last activity)

TAB and SHIFT + TAB is not consistent in a way to set the active descendant.

We should fix that, when pressing TAB to loop through, after it landed on the transcript, it should set the bottommost activity as active descendant if there weren't any active descendants.

In short, when the focus is on the transcript, there must be always one active descendant.

[botkid25]

Another note about this: while using JAWS in Virtual PC mode (which is the default for navigating websites), if you try to press the UP/DOWN arrow keys within the transcript before there's an active descendent set, it will not land on any of the activities. Rather, it will just read out a line in the transcript, e.g., "Sent at July 29th at 2pm".

Once an active descendent is set, using the UP/DOWN arrow keys in the transcript with JAWS Virtual PC mode works fine and will land on an activity with the dashed focus. :)