Settings UI list should be focusless

[joaomoreno]

I find the current settings editor very weird because I can select "rows" within:

It is also an accessibility nightmare, because a blind user will lose time focusing that list and its elements when what he should be focusing are the actual controls, just like a form in a HTML page.

We're currently using the focus to "expand" the description. This adds to the confusion because by selecting a row, the list relays out and other items move down. What we should do instead is present a Read more link, which would do that expansion, for each element.

[roblourens]

This keeps coming up so I will explore it, but I think it will add a hurdle to the normal browsing use case, by making users interact individually with every setting just to read its description. I think that reading a setting happens much more than editing it so we should optimize for that case.

Also, scrolling off the page will be interesting. The tree is virtualized and controls don't exist until they are visible. I guess I can add a fake tab target at the bottom of the list, and when it's focused, reveal the next row and focus it?

[joaomoreno]

Why are we using a virtualized tree/list for this anyway? It's not like there are 10k settings. Why not simple HTML? You could then render all settings with their full description and avoid this focus situation.

[roblourens]

There might not be 10k but there are 1k (with my extensions) and that won't get any smaller. There are input controls and event listeners and it gets redrawn when you search. Seems worth it. Especially as we add more complex controls like for the exclude settings.

[roblourens]

Are you expecting that 'tab' would tab through every link and control of every setting? How would a screenreader user read the setting description? And if they end up in the middle of the list, how do they tab out besides tabbing 1000 times? I think it's better to tab through the main components of the page. When the list takes focus, it will act like any other list in vscode. But at that point the user has to tab or press enter to focus the control, and I don't know how they learn how to do that.

[joaomoreno]

I expect it to work like a simple HTML form: https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/How_to_structure_an_HTML_form

Are you expecting that 'tab' would tab through every link and control of every setting?

👍

How would a screenreader user read the setting description?

Using <label> elements et al.

And if they end up in the middle of the list, how do they tab out besides tabbing 1000 times?

Just like any other control which supports search/filter: press a keybinding to narrow down the search. Ctrl F to go back to the search input field.

[roblourens]

I don't know what screenreader users expect, but I think if the description is in a for the control, it will read the whole paragraph of description text before reading the value, when often they probably want to hear the title then skip to the value which we can do if we separate focusing the setting from focusing the control (like we do now).

[joaomoreno]

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/forms/Basic_form_hints

Check the Describing with ARIA section.

[roblourens]

@zersiax and @cleidigh, I am trying to find the best model for keyboard interaction with our new settings editor and I'd like your opinion on something.

The new settings editor has all settings rendered as a list. Each setting row has a control (checkbox, input box, etc) and possibly some links as part of its description.

Typically a user would see these links and controls and expect to be able to tab through all of them. The problem is that since there are so many targets (hundreds of 1000+ settings rendered at the same time) I've tried to simplify keyboard navigation by rendering the settings as rows in vscode's tree widget, with controls in only one row being focusable at a time.

Under this model, a user would navigate the settings list the same way they would navigate any other list or tree in vscode, using the arrow keys. When a row is selected, the controls and links in that row become focusable, and the user can press tab to focus the controls and links in that row.

My question is, do you think this model would be confusing to users to screenreaders? The alternative is that this page would work not like a list, but more like a typical form, just with a very large number of focusable elements. All controls/links would be focusable and navigation would only use the tab key. This alternative might sound more straightforward/typical but I think the current model is more convenient.

If you try it out, I know there are some accessibility gaps in the current new settings editor. I'm just trying to work out which direction to go.

[cleidigh]

@roblourens
Thanks for the poke. So you know where I'm coming from let me describe my use cases:

I have to do everything by voice, I have zero hand movement from ALS. Almost everything comes down to keyboard commands both built-in and my Python extensions to Dragon. Mouse operations
are very tedious and always meant to be avoided if possible (more and more difficult with moderate UIs)
I actually switched to VS code specifically because it was less icon oriented and with excellent
keyboard support. I got so into it I started contributing a year ago . As I have increased my involvement
I always tend to try and work on the accessibility issues.

When I originally proposed the new drop-down widget the first focus was better layout and theming, but also accessibility with ARIA. So you understand, that was actually my first user experience with screen readers.

Enough of that: My current thoughts:

• As a keyboard navigator, I agree with many of @joaomoreno points. I had some of the similar reactions
  when I first started working with the new settings
• It takes too many keystrokes to get to and change settings currently
• Besides navigation to an individual setting, there is also an issue with the settings keyboard controller
  intercepting up, Down, PageUp, PageDown keys which are normally used to navigate a select
  which is collapsed but responsive to navigation (this is standard HTML, nothing special with my implementation) I would think once the select gets focus these should still be able to work.
• There appear to be scenarios where a screen reader seems to be reading out practically the entire list
  including a million 'clickable' items.
• Header Rows probably should not be focusable, either means more keystrokes and/or screenreader output
• I think the detailed descriptions should be optionally activated by the user, this would avoid a lot of screenreader output , but I also think it would make the layout easier and less cluttered. A usability
  issue here is also when you have clickable/tab indexed items in the description. e.g. Files.Autosave
  I have to Tab three times to get to the drop-down. If the detailed description were opened optionally
  I could skip that.

Extended thoughts:

• I do not have a specific example problem, but I am concerned about some issue of having a virtualized Drop-down, just wondering if something might get crossed with a single instantiation.
• There may be a reason to use ARIA live region control to keep the reader from speaking things in advance
• I think I have gotten into certain situations where nothing seems to have focus and I have to use the mouse to focus something before being able to use the keyboard

I'll keep doing some playing around to provide more feedback

[zersiax]

Making all fields individually tabable doesn't sound like a good idea. It's going to be tricky to determine just from tabbing what belongs to what, as you would need some way of noting what a checkbox you just tabbed to actually toggles. I think that will not scale very well.
This may be overkill, but my first thought when you described the scenario was to make it into a table semantically. That way you have the rows, being the settings, and the columns being the various fields in the list, e.g. title, default setting, action buttons etc.
As for your first idea, that interaction model is rather non-standard; I'd rather expect right arrow to take me to a setting's controls if I'm using up and down arrows to move between settings. Tab wouldn't be my first thought, as usually tab would leave the list rather than move among controls on any given row.

[isidorn]

Agree with some of @joaomoreno points.
Can we look at Keybindings editor as something that already solved a similar problem? First tab focus out of the search and onto the list. Once you are in the list you can use arrow keys to move focus.

On a side note: if a focus is in the settings editor but not inside some input field I would expect typing to go into the Search. This way users could narrow down their search as they are moving focus between elements.

[roblourens]

Thanks for the feedback everyone -

@cleidigh

It takes too many keystrokes to get to and change settings currently

There is a hidden shortcut that helps. If focus is in the search bar, you can press the down arrow key to focus the settings list. But 'tab' still has to stop everywhere in between.

I think this is a pro for the current model though. If the user can use the arrow keys to focus a setting, that's fewer keypresses than tabbing through many links and controls to get to the setting.

Besides navigation to an individual setting, there is also an issue with the settings keyboard controller intercepting up, Down, PageUp, PageDown keys which are normally used to navigate a select

I see this but only on Windows - maybe we can fix this in the custom dropdown control.

There appear to be scenarios where a screen reader seems to be reading out practically the entire list including a million 'clickable' items

I've seen this too, I have some screenreader issues to clear up...

Header Rows probably should not be focusable, either means more keystrokes and/or screenreader output

Agreed, if we keep the current model. I have another issue tracking this.

A usability issue here is also when you have clickable/tab indexed items in the description. e.g. Files.Autosave I have to Tab three times to get to the drop-down. If the detailed description were opened optionally I could skip that.

Another solution would be to make the control the first tab stop within the setting row so that I can tab directly from the row to the control, then tab past it to the links if I want. I do like expanding the description automatically to make browsing settings as easy as possible.

I think I have gotten into certain situations where nothing seems to have focus

Hm, I'd like to know more about that if you can reproduce it consistently.

@zersiax

Making all fields individually tabable doesn't sound like a good idea. It's going to be tricky to determine just from tabbing what belongs to what, as you would need some way of noting what a checkbox you just tabbed to actually toggles.

When you tab to a control, it would read the setting title, value, and description.

my first thought when you described the scenario was to make it into a table semantically

That's interesting. I think I would prefer a model which is close to the layout on the screen. But I will keep that in mind.

As for your first idea, that interaction model is rather non-standard; I'd rather expect right arrow to take me to a setting's controls if I'm using up and down arrows to move between settings. Tab wouldn't be my first thought, as usually tab would leave the list rather than move among controls on any given row.

Thanks for the feedback. I could have the right arrow focus a setting's control! The enter key will do it currently. But, the left arrow would probably go into the control, and not send focus back to the setting.

@isidorn

Can we look at Keybindings editor as something that already solved a similar problem? First tab focus out of the search and onto the list.

We have essentially the same model except that we have additional tab targets inside each row.

On a side note: if a focus is in the settings editor but not inside some input field I would expect typing to go into the Search. This way users could narrow down their search as they are moving focus between elements.

Just like the new outline view, we could do that

[miguelsolorio]

Here's a concept where tabbing will go through all of the input items first, and then using the left/right arrows will navigate to the links/context menu. The difficult part here is making the context menu work on checkboxes + descriptions (that's a separate discussion, though). Thoughts? Here's a high-res photo if the gif is too small.

[roblourens]

I've checked in a new implementation that is only based on tabbing, let me know what you think.

[joaomoreno]

Very cool. I'd close this 👍