Microsoft-ui-xaml: SplitButton's "More Options" button is not keyboard accessible

[carlos-zamora]

Describe the bug

Invoking the "more options" button can't be done with the keyboard. Instead, "Spacebar" and "Enter" invoke the primary action button.

Steps to reproduce the bug

You can test this in the XAML Controls Gallery. Just go to any split button page.

Steps to reproduce the behavior:

1. Attach keyboard focus to splitbutton (just clicking on the primary button can do that)
2. Press "Spacebar" or "Enter" to invoke it --> invoke primary action button
3. Press "left" or "right" arrow keys --> nothing happens

Expected behavior

One of the two (though I bet the first aligns better with how touch operates):

1. "Spacebar" or "Enter" would invoke the dropdown button. Then there's no way to directly access the primary action button. "Left" and "right" arrow keys are disabled.
2. "Left" and "right" arrow keys let you select between the two options. Then, "Spacebar" or "Enter" invokes focused option. Default focus would fall to the primary button.

Screenshots

Just check the XAML Controls Gallery

Version Info

Just check the XAML Controls Gallery

NuGet package version:

Just check the XAML Controls Gallery

Microsoft Windows [Version 10.0.18963.1000]

| Windows 10 version | Saw the problem? |
| :--------------------------------- | :-------------------- |
| Insider Build (xxxxx) | |
| May 2019 Update (18362) | |
| October 2018 Update (17763) | |
| April 2018 Update (17134) | |
| Fall Creators Update (16299) | |
| Creators Update (15063) | |

| Device form factor | Saw the problem? |
| :-------------------- | :------------------- |
| Desktop | |
| Mobile | |
| Xbox | |
| Surface Hub | |
| IoT | |

Additional context

[mdtauk]

Focus probably should select the Primary half with the Chevron half the next tab along

[chingucoding]

Focus probably should select the Primary half with the Chevron half the next tab along

I agree with @mdtauk. This makes a whole lot more sense from a user perspective.

[mdtauk]

[jevansaks]

Alt+Down opens the split options, consistent with the Office control set. With narrator, the secondary action should open the overflow.

[YuliKl]

SplitButton is working as designed. I'm open to revisiting the ability to move focus to the individual halves, although this may present some interaction design challenges.

It's important that the SplitButton control remain a single Tab stop (and users aren't forced to hit Tab multiple times to move focus past SplitButton to the next control). Given that both halves of the button are a single Tab stop, we probably wouldn't draw focus around only one of the parts. Arrow keys could move focus within SplitButton - but I'm not sure which arrow direction would be intuitive to move focus to one of the halves, and to which half. The arrow directions are intuitive when a half has focus, but less so when the whole does.

I've been told that Alt+Down is the industry standard for interacting with this type of UI.

[mdtauk]

@YuliKl Having the two halves act as separate buttons, would probably be more intuitive, as I know I certainly was not aware of having a different key combination to operate this control. And it would also solve the problem of the ToggleSplitButton supporting Toggle in touch too.

[YuliKl]

@YuliKl Having the two halves act as separate buttons, would probably be more intuitive, as I know I certainly was not aware of having a different key combination to operate this control.

Well now you know the secret handshake 😉

And it would also solve the problem of the ToggleSplitButton supporting Toggle in touch too.

Touch has its own complications. Right now, the chevron half is too small to meet touch-ability requirements. While touch targets need to be measured in physical units like cm, which aren't readily available when designing scale-able UI, we've done approximations and projections to estimate minimum sizes in pixels. To be considered usable with touch, a touch target should be either 44x44 px or 32x120 px. We can sometimes fudge these numbers a little bit and shrink the pixel sizes, but not if the touch target is immediately adjacent to another touch target, as is the case with split button parts.

[mdtauk]

@YuliKl Having the two halves act as separate buttons, would probably be more intuitive, as I know I certainly was not aware of having a different key combination to operate this control.

Well now you know the secret handshake 😉

And it would also solve the problem of the ToggleSplitButton supporting Toggle in touch too.

Touch has its own complications. Right now, the chevron half is too small to meet touch-ability requirements. While touch targets need to be measured in physical units like cm, which aren't readily available when designing scale-able UI, we've done approximations and projections to estimate minimum sizes in pixels. To be considered usable with touch, a touch target should be either 44x44 px or 32x120 px. We can sometimes fudge these numbers a little bit and shrink the pixel sizes, but not if the touch target is immediately adjacent to another touch target, as is the case with split button parts.

Have you considered using Tap and Hold to bring up the flyout, with a Tap designed to trigger the Button's click event?

[YuliKl]

Have you considered using Tap and Hold to bring up the flyout, with a Tap designed to trigger the Button's click event?

Yes, we did considered this. But tap-and-hold is the touch equivalent of mouse right-click, so not quite the right concept. Tap-and-hold is also overloaded to show a tooltip while holding (the tooltip dismisses when I lift my finger). So keeping existing behavior in mind, showing a split button's flyout on tap-and-hold didn't feel quite right.

Having said all that, we know the touch behavior of split buttons needs improvement and are tracking this issue with #178.