Active View Switcher Accessibility Issues

[SaschaCowley]

• VSCode Version: 1.49.0 (e790b93)
• OS Version: Windows 10.0.19041 .450x64

Issues:

• Per Tab lists should only occupy a single tab stop #106438, the activity switcher should only occupy 1 position in the tab order.
• Only the currently selected activity view should indicate it is selected (including none if the sidebar is hidden).
• Navigation by arrow keys should also be possible with left/right arrows, as this is the standard behaviour of tab list controls. I suggest that the up/down navigation be kept as well to align with the visual presentation.

Does this issue occur when all extensions are disabled?: Yes/No
Yes.

[isidorn]

Teh active view switcher uses the action bar widget as an implementation detail. So if we fix #106441 this will be fixed as well. Thus closing as duplicate

[SaschaCowley]

@isidorn That issue only addresses one of the issues identified here.

[isidorn]

Yeah let's reopen for discussion but
2) we set aria-expanded = true on the one which is selected. What do you suggest we do here, that we also set aria-selected?
3) I have changed this in the past, for the activity bar to always respect both arrow keys, however that broke some menu navigation and I had to revert the change. Though we can try to re-apply it

[SaschaCowley]

When I navigate through the view switcher, this is what I hear (with the explorer view active and using NVDA 2020.2):

Active View Switcher tool bar
Explorer (Ctrl+Shift+E) active tab selected expanded Explorer (Ctrl+Shift+E)
Search (Ctrl+Shift+F) tab selected collapsed Search (Ctrl+Shift+F)
Source Control (Ctrl+Shift+G) tab selected collapsed Source Control (Ctrl+Shift+G)
...

Whereas what I would expect to hear is:

Active View Switcher tool bar
Explorer (Ctrl+Shift+E) tab selected
Search (Ctrl+Shift+F) tab
Source Control (Ctrl+Shift+G) tab
...

Some of the verbosity may be of NVDA's doing, but, using the examples linked in #106438, I get output as per above. I suspect that some extraneous ARIA properties are being set here.

Is there a way with which I can inspect what is going on under the hood in Code?

[isidorn]

We actually got feedback from some of our users that for the activity bar the current behavior is what is prefered.
I also think it makes more sense since the activity bar item is actually expanded. And if were to also announce selected I feel like that would be too much. So IMHO I would not change anything

As for looking at items under the hood of VS Code. F1 > toggle developer tools > you can try to use google chrome dev tools to inspect varios vscode html elements

[SaschaCowley]

We actually got feedback from some of our users that for the activity bar the current behavior is what is prefered.

Okay. It seems nonstandard and odd to me, but if you have research showing otherwise, fair enough.

I also think it makes more sense since the activity bar item is actually expanded. And if were to also announce selected I feel like that would be too much. So IMHO I would not change anything

They have the ARIA role "tab", so should behave like tabs. That means being selected or unselected, which essentially means expanded or collapsed. If expanded/collapsed is preferred, something like a button should be used instead.

I think the reason I am hearing the items' names read out twice is that both aria-label and title are set. Is there a reason for this?

I'm not sure why I am hearing "selected" as well on all items, as it doesn't seem to be set on any items. Could be something to do with the "tab" items not being in a "tablist", or the nonstandard use of aria-expanded. I am experiencing it with both NVDA and Narrator.

[isidorn]

It is not deep research, just a discussion among users and me. More details here #97563
I was not aware of the "tab can only be selected not expanded" rule that you mention. Is that documented in the Aria spec or is just standard behavior for all apps?

Yes, we set both the aria-label and the title, because the title is there for when the user hovers over the element with the mouse, and aria-label we set on all elements. It is up to Screen Readers to de-dupe this, and actually both Orca on Linux and VoiceOver on mac do this correctly. NVDA issue is here nvaccess/nvda#7841

We could add the tablist on the parent element, or change to set selected and not expanded. But let's wait on some feedback from the community.

[SaschaCowley]

I was not aware of the "tab can only be selected not expanded" rule that you mention. Is that documented in the Aria spec or is just standard behavior for all apps?

This was my bad, as I was going from standard behaviour. The spec says:

For a single-selectable tablist, authors SHOULD hide other tabpanel elements from the user until the user selects the tab associated with that tabpanel. For a multi-selectable tablist, authors SHOULD ensure each visible tabpanel has its aria-expanded attribute set to true, and that the remaining hidden tabpanel elements have their aria-expanded attributes set to false.
In either case, authors SHOULD ensure that a selected tab has its aria-selected attribute set to true, that inactive tab elements have their aria-selected attribute set to false, and that the currently selected tab provides a visual indication that it is selected. In the absence of an aria-selected attribute on the current tab, user agents SHOULD indicate to assistive technologies through the platform accessibility API that the currently focused tab is selected.

https://www.w3.org/TR/wai-aria/#tab

[isidorn]

Makes sense. So assigning this one to September to make sure that I set aria-selected on activity bar elements. And to support left / right navigation

[isidorn]

I have pushed a fix for this, you can try it out with latest vscode insiders from Thursday and let us know how it goes.

[SaschaCowley]

Using Code-Insiders 1.50.0-insider (3156f1f)

• "Selected" seems to be correctly used now.
• Left/right arrows navigate the toolbar
  • When using left/right arrows, navigation stops at the end of the "active view switcher" or "manage" toolbar, but when using up/down arrows it doesn't (IE with left/right you have to tab or up/down to change toolbars).
• Is there a reason "active" is being appended to the tabs' names? Surely the role information conveys this already?

[isidorn]

All very good points. I have pushed a commit to tackle both issues you outlined.
Thanks a lot for great feedback!
You can try it out with VS Code insiders from Monday and let us know if things are good for you now, I tried and all seems good.