Fluentui: CommandBar button positions are not read properly by ATs

[brandonthomas]

Environment Information

• Package version(s): 7.86.1
• Browser and OS versions: NVDA/FF, Narrator/Edge Chromium -> all Windows

Describe the issue:

When navigating the CommandBar, the left and right options are treated as a single widget and navigated with the arrow keys. However, they are read by screen readers as two separate groups of controls. In the example NVDA and Narrator both read the left controls as 'n of 5'. However, when you get to the controls on the right it is read as 'n of 2' on Narrator. When using NVDA both buttons on the right are read as "1 of 1" even though there are two. Since this is navigated as a single widget the set size should include all controls so in this case that means reading it as 'n of 7'.

Please provide a reproduction of the issue in a codepen:

https://codepen.io/brandonthomas/pen/XWJwyrr?editable=true -> simply the default codepen from the demo site

Actual behavior:

Left and right commands within CommandBar are read as two groups of buttons yet navigated as a single widget.

Expected behavior:

Left and right commands within CommandBar are read as a single group of buttons OR read separately and tabbed into separately.

Documentation describing expected behavior

WCAG 2.0: Info and Relationships: Understanding SC 1.3.1
https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html

[khmakoto]

Hi @brandonthomas, thanks for filing this issue! I think this happens because of the definition of near and far items in the CommandBar but I understand the confusion that this can cause.

@micahgodbolt what is the expected behavior here? Should these groups be read separately or as part of a singular unit?

[brandonthomas]

@khmakoto for additional context we had an accessibility issue filed against our controls on this one since they use CommandBar under the hood. My expectation and I think users' would be that if it behaves as a single widget the set size includes all items you can arrow to. I also understand the need to have them separate so maybe both far and near have their own FocusZone that you could tab through. Just trying to think of the possible ways to handle this and alleviate confusion.

[brandonthomas]

@xugao as FYI since we have a thread together on this.

[ayuspark]

Hello, I'm wondering if there's an update on this?

Our product within the Dynamics group also experience the same situation.
For instance, if a command bar contains 1 menu item, and a search bar, the narrator would only say: "XXX", item 1 of 1. As a result, user wouldn't know of the Searchbar on the CommandBar component.

Also echoing brandonthomas' scenario on the near/far items.

Mention @micahgodbolt for awareness :)

[smhigley]

Just came across this one :).

The more I think about it, the more I'm inclined to think that treating them as separate widgets might be a good thing -- the visual language of left/right separation often means that the groups are meaningfully distinct and perform different sorts of actions on different scopes of UI. For example, in the codepen/default example, I can imagine that the right group of actions do something to a specific row or item within a set while the left two buttons affect the grid/set as a whole. In that example, having two separate menubars is semantically fitting.

That might not perfectly match all uses of CommandBar by all authors, but still seems like a reasonable base approach. If that reasoning makes sense to everyone else, I think the solution would be to have the left and right groups be separately tabbed to, and not allow arrow keys to move between them.

[brandonthomas]

Yah I think I'm ok with that suggestion as long as, like you said, they are separate tab stops. Right now arrowing goes between them so it's pretty confusing as you think you're at the end of the widget when you're not.

[brandonthomas]

@khmakoto thoughts?

[khmakoto]

I think that's perfectly acceptable and may be even desirable. It would need to be tackled on a major revision though since changing that functionality now would be breaking. If we are good with that I guess we can remove the Needs: Discussion tag and move this issue to the backlog.

[brandonthomas]

Awesome. Can you expand on why it's a breaking change and not seen as a patch? Do we need to make DOM related changes? I was thinking we'd just tab between both overflow sets but I wasn't sure what that might mean. Hoping it's a patch though since we have active a11y bugs against us for this.

[khmakoto]

I could double check on this but I thought there was some fundamental structural change we were going to have to make. I could be mistaken though.

[ayuspark]

Hi, @khmakoto , wonder if there's an update?
We also have an a11y bug (needs to fix within 60 days back when they were filed).

[ayuspark]

hi all, seems like there are changes made to this issue -- I revisit the bug and now I see that screenreader is reading # of item including both the near and far items.

e.g. it'd read the following commandbar screenshot as if user selects the first item on the menu:

"1 of 7 item". Instead of "1 of 5 items" 20-ish days ago.

Even though it doesn't align with what @smhigley initially suggested, "... having two separate menubars is semantically fitting."

(This is to update this thread.)

[JustSlone]

tagging @khmakoto, to help follow up on this