Fluentui: Split button in Commandbar: [Keros bug]: Buttons must have discernible text

[saini-ankish]

Environment Information

Package version(s): >6.111.2

Browser and OS versions: chrome version 69.0.3497.100 and OS version windows 10

Bug repro URL: CodePen

Here IContextualMenuItem have an option to split but no option to provide splitButtonAriaLabel.

Actual behavior:
Keros issue : Buttons must have discernible text

Expected behavior:
keros should not give any issue

[dzearing]

@jspurlin @joschect Is there something the developer using the split button needs to do here?

[Vitalius1]

So I did a little bit of investigation and it looks like if following the chain of props below you can still pass the splitButtonAriaLabel prop to the command bar items.
CommandBarItem is of type ICommandBarItemProps which extends from IContextualMenuItem interface. This interface, in turn, has this:
https://github.com/OfficeDev/office-ui-fabric-react/blob/ae66c05a20ddf23c37fd92a1d3528815e15cc45c/packages/office-ui-fabric-react/src/components/ContextualMenu/ContextualMenu.types.ts#L471-L474
...which means you can still pass the splitButtonAriaLabel and have it applied on the chevron down icon button of the split button. Here is your codepen with the prop added.

@saini-ankish let us know if this solution works in your case.

@joschect with the prop I linked above it seems we can add anything to IContextualMenuItem... is this even type safe when we try to pass the props added like that further down the chain?

[jspurlin]

Since the whole splitButton is the focusable button, it's not required that the nested controls have a label. This should like something that should be followed up with the keros/insights team

[saini-ankish]

@Vitalius1 Passing splitButtonAriaLabel resolves it

[Vitalius1]

@jspurlin, @dzearing looking at the design toolkit I see that the splitMenuButton is focused separately:

What is the correct behavior?

[jspurlin]

No, this does not align with the current behavior, which is:

• Only the whole splitButton is focusable
• ENTER/SPACE executes the primary button
• ALT+DownArrow executes the secondary button (e.g. expands the menu)

[khmakoto]

@Vitalius1 given that you said splitMenuButton instead of splitButton you might be looking at the one in experiments. In that case I should say that none of the Buttons in the experiments package are fully optimized for accessibility yet.

[Vitalius1]

@jspurlin I guess this means we need to communicate this to designers so that they don't put an incorrect behavior in the toolkit.

Also, do we just need a PR with fixing the examples for the CommandBar by including these aria-labels? Even if we add them from my understanding they will not be read by a screen reader because we can not tab to them so this feels like just making Keros stop complaining 😄

[Vitalius1]

@dzearing would love to hear your opinion too as to how to proceed with this issue.

[dzearing]

hmm.

   [propertyName: string]: any; 

Disables type safety. It helps in some cases but basically makes it easy to have bugs. That said, it's the only way I know of to allow data-* attributes to be passed along.

[Vitalius1]

@saini-ankish is this issue manifesting somewhere on our website? Our CommandBar examples are not using the SplitButton so I am confused where this issue is manifesting.

[saini-ankish]

@Vitalius1 not actually on fabric website i faced this issue in my project.

[msft-github-bot]

This issue has been marked as being beyond the support scope of UI Fabric's issues board. It will now be closed automatically for house-keeping purposes.