Toolbars should only occupy one tab stop

[SaschaCowley]

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

Steps to Reproduce:

1. Enter a toolbar (EG. focus the explorer view, tab to the "Folders" section, and tab to the toolbar.
2. Attempt to Tab out of the toolbar.

The standard behaviour is that the tools in the toolbar occupy only a single position in the tab order, and are navigable with the arrow keys. While navigation by arrow keys works, each toolbar item still occupies its own position in the tab order.

See Toolbar Example.

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

[isidorn]

@SaschaCowley thanks a lot for providing feedback. I would be open to making this change, however I first pinged our accessibility community on https://gitter.im/Microsoft/vscode-a11y to get their feedback

[MarcoZehe]

I am in support of this change. Reduces the number of tab stops and is a well-known pattern.

[isidorn]

@MarcoZehe thanks for feedback. I will expriment with making a change regarding this some time in January

[isidorn]

I really like this change, however I would prefer to do it at the start of a milestone to have a full milestone to gather feedback, thus assigning to February.
I have aslo shared this in the vscode team to gather more feedback.

I have a PR branch which is work in progress and I plan to continue on it in February #114769

[webczat]

hmmm actually this would fix one more thing. there is the weirdness that you can forward-tab through all toolbar items, but when you are in the explorer tree and shift+tab you don't land on the buttons themselves. that may be not fully related because I believe you don't land on any of the buttons so you would have to tab once anyway.

[MarcoZehe]

@isidorn When are you going to finish and merge this so we can try it out? Sounds like an interesting change.

[isidorn]

@MarcoZehe I plan to look into this later today / early next week. So expect an Insiders with this on Monday / Tuseday next week.

[isidorn]

Started working on this and seems to work ok and I plan to push to insiders soon.

One corner case which I hit:
Some toolbars inside have the input box (for example the problems view title and the debug console title area have the filter input).
So if the focus is inside the input box left and right navigation is taken by the input box navigating to the left or right inside the input.
So the question is how to move focus out if you are in the inputbox inside a toolbar. I see two options:

1. When you are navigated all the way to the left in the inpubox pressing left would take the focus out of it. Same for right
2. tab would take the focus out of the input box. That way we would treat the input boxes a bit special compared to other actions

Let me know if you have other ideas.

[MarcoZehe]

One corner case which I hit:
Some toolbars inside have the input box (for example the problems view title and the debug console title area have the filter input).
So if the focus is inside the input box left and right navigation is taken by the input box navigating to the left or right inside the input.
So the question is how to move focus out if you are in the inputbox inside a toolbar. I see two options:

1. When you are navigated all the way to the left in the inpubox pressing left would take the focus out of it. Same for right
2. tab would take the focus out of the input box. That way we would treat the input boxes a bit special compared to other actions

For this, the Toolbar Design Pattern has an answer: Make the edit box the last item in the toolbar, and allow LeftArrow to move out of it, but RightArrow should just stay at the end if reached.

[MarcoZehe]

@isidorn In addition to the official version, in Firefox we took a slightly different approach:

1. We trap the left and right arrow keys in a container until we reach a text field.
2. Then, it is trapped inside the text field, both left and right.
3. Tab and Shift+Tab take us out of that back into the container that also contains the text field, onto the next or previous control respectively.

It's a little more complex, but also has the advantage of being more flexible with the location of a text field within such a toolbar container. And I believe MS Office takes a similar approach to that, e.g in the Ribbons in Word or Excel.

[isidorn]

@MarcoZehe thanks a lot!
We can not change the order of items in the toolbar since that would break existing users, so we can not make the edit box the last item in the toolbar.

Firefox approach sounds like my option 2. I personally think it is nicer. Also it is good to be aligned with Office.
So let me try implementing that..

[alex19EP]

just my two cents. i prefer the second variant too.

[isidorn]

I have pushed a first version of this, please try it out in tomorrow's vscode insiders and let me know how it goes. Thanks!