Microsoft-ui-xaml: Proposal: Update CommandBarFlyout's keyboard behavior

[YuliKl]

Proposal: Update CommandBarFlyout's keyboard behavior

Summary

We should optimize the number of keystrokes required to move focus to a given item within an open CommandBarFlyout. One way to streamline keyboard navigation is to reduce the number of Tab stops.

Rationale

Today, every item in CommandBarFlyout's primary area is a Tab stop. To navigate to the first secondary item, users are forced to Tab through all primary items and the More button. These extra key strokes are inefficient and cumbersome for power users and people with physical disabilities. Reducing the number of keyboard interactions necessary to move focus to the first of the secondary options will improve the experience for all keyboard users.

Functional Requirements

| # | Requirement | Priority |
|--- | --- | --- |
1 | Keyboard users are able to reach a desired command with as few keystrokes as possible | Must
2 | Both blind and sighted users are able to navigate through CommandBarFlyout in a logical order using keyboard | Must

Proposed Design

• Tab key:
  
  
  
  • Only the first primary and the first secondary items are tab stops; More button will not be a tab stop
  
  
• Right arrow:
  
  
  
  • In primary commands, moves focus to the right
  
  
  • On More button, does nothing
  
  
  • In secondary commands, does nothing (unless the secondary command is a special cascading item; not shown in the prototype)
  
  
• Down arrow:
  
  
  
  • In primary commands, moves focus to the right
  
  
  • On More button, moves focus down (to the first secondary item)
  
  
  • When secondary commands are collapsed and focus is on More button, opens the overflow and moves focus to the first secondary item
  
  
  • In secondary commands, moves focus down
  
  
  • When on last secondary item, moves focus to the first primary item
  
  
• Left arrow:
  
  
  
  • In primary commands, moves focus to the left
  
  
  • On More button, moves focus to the left (to the last primary item)
  
  
  • In secondary commands, does nothing
  
  
• Up arrow:
  
  
  
  • In primary commands, moves focus to the left
  
  
  • When on first primary item, moves focus to last secondary item
  
  
  • On More button, moves focus to the left (to the last primary item)
  
  
  • In secondary commands, moves focus up
  
  

Important Notes

We need to update the UIA structure of primary commands and More button such that Narrator will announce the More button as the last item in the primary list. In this example:

Narrator will announce

• Share app bar button, 1 of 4
• Save app bar button, 2 of 4
• Delete app bar button, 3 of 4
• More app bar button, 4 of 4

Open Questions

1. Q: Should pressing Space bar while focus is on the More button move keyboard focus?
   A: No. When activated with Space focus should remain on the More button to give Narrator an opportunity to announce the state change to the secondary commands (visible or collapsed).

2. Q: Should every item in CommandBarFlyout be a tab stop to enable moving focus between items, including ones that handle arrow keys (e.g. TextBox)?
   A: No. This proliferation of tab stops would impede usability by reducing the efficiency of Tab vs. arrow. We consider CommandBarFlyout to be made up of two lists: a horizontal list of primary items and a secondary list of secondary items. Tab key should move focus between the two lists but not within them.
   App developers need to be aware of this design and avoid putting controls that handle directional navigation via arrow keys into their app's CommandBarFlyout. For example, don't add a ComboBox to secondary items.

[kmahone]

Currently up/down keys only move between More Button and secondary items. It would probably be better if you could also use up/down to move from primary items into the secondary items. Right now, from the first primary item you have to go Right, Right, Right to get to the More button, and then press Down to get the the secondary items. It would be quicker to be able to directly go down.

[jevansaks]

@yulikl You filed this as a "feature request", are you going to bring it through the pitch process before dev should pick it up?

[llongley]

This sounds great to me - I've already heard from one customer who wanted to know how to do this. Should we perhaps also bring this same behavior to the CommandBar? It has always seemed strange to me how tab moves through all the primary commands and then just in and immediately out of the secondary commands.

I'm also curious if we should make the right key continue to iterate through the secondary commands, if we did your fourth idea - it'd seem odd if it visually moved focus vertically once but then no more after that.

[MikeHillberg]

Shift-tab is a way to do the original scenario here. But I like Keith's suggestion which is basically that command flyout should support 2D navigation using the keyboard.

[YuliKl]

Thank you for the suggestions! We need to ensure that CommandBarFlyout works well for both sighted and blind users. In talking to our resident SME, blind users definitely want to use the arrow keys and expect that down (or right) will take them to the next item. CommandBarFlyout's secondary commands are drawn directly below the primary commands. So following 2D navigation, down from the first primary item will move focus to the first secondary item - not what a blind user expects to happen because the "next" item is primary item2, not secondary item1. To avoid moving focus to an unexpected place (for either blind or sighted users), I believe it will be best to prevent the down key from moving focus at all (except from the More button).

I really like the suggestion of having the right key move focus through all secondary items. However, this interaction may run into a collision with any complex controls or subitems that also handle the right arrow key for an action other than moving focus. We should prototype and work through detailed implications that I haven't thought of yet.

While updating CommandBar is outside the scope of this proposal, I'm open to changing that control in the future as well. @llongley , are there specific customers who you know have run into issues with CommandBar?

[YuliKl]

I've updated the issue with agreed-on design resulting from review on 3/27/19

[msft-github-bot]

:tada:This issue was addressed in #545, which has now been successfully released as Microsoft.UI.Xaml v2.2.190430003-prerelease.:tada:

Handy links:

• Release Notes
• Official Nuget Release

[YuliKl]

Incorrect behavior that I'm seeing:

• Down arrow from last primary item should move focus to More button
• Down arrow from last secondary item should move focus to first primary item
• Up arrow from first secondary item should move focus to More button

[msft-github-bot]

:tada:This issue was addressed in #545, which has now been successfully released as Microsoft.UI.Xaml v2.1.190606001.:tada:

Handy links:

• Release Notes
• Official Nuget Release

[chigy]

@yulikl , did any documentation or sample app get updated as a result of this feature? I'm not seeing the indication of it and I feel the keyboard guidance might need some additional info added? (Sorry if this was the same one you already updated... :|)

[YuliKl]

@Chigy - Xaml Controls Gallery now shows the correct behavior. I updated the (Popup UI)[https://docs.microsoft.com/en-us/windows/uwp/design/input/keyboard-interactions#popup-ui] section of the keyboarding doc to talk about cycling.

[chigy]

Moving to archive.