Keyboard navigation in settings editor is broken

[russelldavis]

Issue Type: Bug

1. Open the settings editor
2. Click on an empty place on the page so it has the focus
3. Press down/up/pagedown/pageup to navigate.

Expected: The settings page should scroll
Actual: Nothing happens

Related issue: I tried to navigate using tab instead of the arrow keys. That looked promising, but it only scrolls down partially through the list. It looks like there's some dynamic loading of further settings that normally happens when using the scroll wheel that doesn't happen when using tab to navigate. In the Insider Build, using tab won't even cause the page to scroll at all.

Given both of these issues, navigating through multiple options in the settings page via the keyboard is currently impossible :(

#54039 seems like a relevant change that may be related. cc @roblourens

VS Code version: Code 1.30.2 (61122f8, 2019-01-07T22:48:31.260Z)
OS version: Darwin x64 18.2.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (8 x 2800)
GPU Status	2d_canvas: enabled checker_imaging: disabled_off flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: enabled rasterization: enabled video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled
Load (avg)	2, 2, 2
Memory (System)	16.00GB (0.05GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions (8)

Extension	Author (truncated)	Version
vscode-custom-css	be5	3.0.3
solargraph	cas	0.19.1
applescript	idl	0.14.2
theme-dark-plus-contrast	k3a	0.1.101
python	ms-	2018.12.1
ruby	reb	0.21.0
vscodeintellicode	Vis	1.1.2
change-case	wma	1.0.0

(1 theme extensions excluded)

[roblourens]

It would be nice if the I guess the arrow keys, page up/down, and even spacebar worked to scroll the settings list. But the recommended way to navigate with the keyboard is by tabbing. Unfortunately it seems to be broken in stable due to some paging related issue like you identified. Fortunately we are getting rid of that paging so it should work in the next update.

[russelldavis]

we are getting rid of that paging so it should work in the next update.
Great to hear, thanks!

It would be nice if the arrow keys worked

IMO, it's more than just a nice to have. It's a standard way to scroll every scrollable thing, almost universally. You mention that the recommended way to navigate is by tabbing, but where is that recommended? I only discovered that by searching through github issues.

I'm guessing that when most keyboard-preferring users see a long list of scrollable content, they reach for the arrows/pageup/pagedown, not tab.

Anyway, just my two cents, thank you for your work on this!

[roblourens]

Yeah I think I agree with that. However it's not easy to do with our virtualized list.

@joaomoreno I don't think there are any other applications of the tree where we would want to scroll by page up/down or arrow keys as if it's normal content overflowing (not by selecting the next item in the list) right? Also we would want smooth scrolling but I think it would end up feeling non native.

[joaomoreno]

A good analogy would be the Markdown viewer, in which arrow and page keys move the view pane. It would be cool to have that in the Settings editor too. A couple things which we would need to do:

• We'd need to handle the keydown event ourselves on the outer guy and just call .scrollTop += diff on the tree.
• It doesn't seem possible to get that sweet Chrome scroll animation, so we'd have to simulate it, which shouldn't be too hard.
• We'd also need the focus outline decoration around the whole editor to provide the affordance that the area is actually interactive.

[roblourens]

It doesn't seem possible to get that sweet Chrome scroll animation, so we'd have to simulate it, which shouldn't be too hard.

It would be easy to simulate an animated scroll, but it wouldn't have the exact same parameters as what Chrome uses, so I'm worried that it would feel non-native. But maybe it can be close enough for nobody to notice.

I tried to hack this up with SmoothScrollableElement and ran into https://github.com/Microsoft/vscode/blob/master/src/vs/base/browser/ui/list/listView.ts#L897 messing with the scrollTop when rendering while smooth scrolling.

We'd also need the focus outline decoration around the whole editor to provide the affordance that the area is actually interactive.

I disagree, it should look like normal page content which doesn't have a focus outline.

[isidorn]

There are user which are using vscode via a screen reader that hit this issues.
Thus adding accessibility label.
@roblourens are there some plans to tackle this. I just tried and the keyboard navigation is settings is broken. I would not expect that it scrolls up and down but just that it navigates through the settings.

The extensions view is also using a virtualised list and there the navigation is working great imho.

[roblourens]

Setting rows are not selected, so normal list navigation will not work. It will take some effort and we will have to reimplement smooth scrolling, page up/down, etc. It should not be an accessiblity issue because it's still easy to navigate by tabbing right?

[isidorn]

@roblourens why don't we select the settings rows? What's the downside of that?
Well sure tab navigation works, but this is different from all our other list where we support up / down thus I find this confusing and inconsistent.

[roblourens]

It worked that way in an earlier version of the settings editor, and we decided it was very confusing. Users see the settings editor as a form, not a list, so it should work like other forms. The "list" is an implementation detail.

[isidorn]

@roblourens I personaly do not see how up/down navigation is more confusing than the current state of affairs where up/down simply flips through the values of a focused setting - am I missing something here?
I understand that the "list" is an implementation detail but users might expect to navigate through the settings like a table, and for that up/down should navigate. Some similar feedback #52815
Oh I also found that we had this same exact discussion more than a year ago #57372
At least I am a man of principle and did not change my point of view :D

[roblourens]

I liked the old way of navigating through setting items so I am not going to argue with you on that, but I'm not going to fundamentally change the ux now.

[Pawper]

Sorry if I am intruding here, I appreciate all the hard work done by everyone here on VS Code. I do appreciate the settings editor as I had trouble with only using the JSON file before the editor was available. However, I have had my own experience navigating the editor (please read below) and I'm not satisfied with the resolution I reading. I am new to web development, so please forgive me if I am missing the expertise, but I want to share my point of view.

I just tried to navigate the settings editor to find a setting I didn't know the name/ID of and found I cannot scroll using the keyboard. My desk space is limited so I like to use keys like PgUp/PgDn to scroll. Using tab to navigate and find an unknown is very slow and burdensome.

It was also very difficult to move my focus out of the settings page. I used Ctrl+F to focus on the search bar and from there I could tab around the broader VS Code UI. But once you are in the settings editor, it seems you are trapped in a way without knowing some non-intuitive keybinding as a means for navigating out.

But the recommended way to navigate with the keyboard is by tabbing.

Users see the settings editor as a form, not a list, so it should work like other forms.

If the settings editor is a form then it is, I feel, not the best form design. From what I have learned in my recent studies, a single page form with hundreds of items like this is best suited for data entry by people very familiar with the form, which doesn't seem to be this context. Is tabbing through all these items as a means of navigation practical or accessible in some way? It's not been my experience.

I don't think users see the settings editor as a cohesive form, the traditional one that a user would go through item-by-item and "submit". I suspect they see it as a page of sections containing form elements. Perhaps, semantically, this should be considered as something else.

I hope this helps.

[roblourens]

After major changes this summer, this will work more like other lists, and keyboard navigation is much nicer