Screen reader users have a difficult time navigating the settings pane

[ajborka]

@isidorn: Screen readers have a difficult time navigating the settings window. It appears that the actual settings are contained in a continuously scrolling panel. There is no way for a screen reader user to scroll down the list unless he or she presses TAB to cycle through all of the settings. This is slow and not very effective.

• vscode version: 1.44 (Insider's)
• OS Version: Windows 10 (1909), Ubuntu 20.04

Steps to Reproduce:

1. Start JAWS or NVDA if on Windows, or Orca if in Linux.
2. Start vscode Insider's.
3. Press ctrl+, (comma) to open settings.
4. Choose a category from the settings tree. Commonly used is a good option because it is a long list of settings.
5. Use screen reader navigation to review the settings panel.

Actual results: Settings are hidden from screen reader view and are often overlooked by some users.
Expected results: Screen reader users can navigate each setting category without having to scroll the screen to reveal settings hidden from view.
Does this issue occur when all extensions are disabled?: Yes

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Screen reader doesn't read total count and relative position of item in intellisense (#88436)
• cannot read entire code file when using JAWS or NVDA (#89717)

[isidorn]

Similar as #92488 let's assign to @roblourens

@ajborka @jvesouza I would be interested in your feedback with the settings JSON editor which you can get via F1 > preferences Open Settings (JSON). If you think that is a better experience we might change it to be the default once screen reader is detected.

[ajborka]

@isidorn,
The json settings editor might not be the most intuitive option for new users, or those not familiar enough with json or vscode settings to feel confident while making reasonable choices with settings. As a new user, I shouldn't have to look through a huge list of settings online to see which ones I need to use.

[isidorn]

@ajborka agree that it is less intuitive and takes a bit of a learning curve. However once you get used to it it is acutlly more efficient. Sicne there is inteli-sense which proposes all the settings and it can be quite easy to find what you need.
Thuogh agree with you it is not good for new users.

[jvesouza]

@ajborka @isidorn I am not the best person to give an opinion on this because clearly my opinion will take into account my profile. I started working with mainframes and in the mainframes, at least when I worked with them, the interface was via the command line and the settings were made using text files or punched cards! Even when I started working with Linux, I always prioritized the command line interface. Because of that, I feel perfectly comfortable with the suggestion to edit preferences directly in the json file.

[ajborka]

@isidorn , @jvesouza : Maybe it wouldn't hurt to use the json editor if vscode detects a screen reader. However, this means you will have to implement detection routines for Orca, if you haven't already created them. The other concern is that the json settings editor only shows modified settings. The only way to get a list of settings with default and possible choices is to have a split editor with default settings/values on one side, and modified values on the other. Good for people who don't use a screen reader. We need to figure out how to implement the json editor so it will work with both sets of users. I like the idea of having a setting called editor.screentips that when turned on will provide tips/hints to the user. These tips can be provided to a screen reader when accessibility is turned on. One of these tips could be a modified tag to notify the user that the setting is not the default. It works similar to the modified flag in the settings UI. Let me know what you think.

[isidorn]

@jvesouza @ajborka thanks for feedback!

@ajborka we already know if the user has screen reader attached or if he has editor.accessibilitySupport turned on, so detection is not a problem.
For the default settings we have the command F1 > open default settings.
So in theroy when we detect a screen reader we could open two editors side by side, on the left the defaults settings one, on the right the modified ones.

As for the tips, that usually makes sense, however it usually conflicts with our goal of making vscode minimalistc thus we always aim to have good resources outside fo vscode like documentation and website. So not sure what would be the best thigns to do here, but a VS Code stlye would be just to improve our docs.

[ajborka]

@isidorn , do you have a page describing all of the settings for vscode? Maybe I can take a look and give some ideas.

[jvesouza]

For the default settings we have the command F1 > open default settings.
So in theroy when we detect a screen reader we could open two editors side by side, on the left the defaults settings one, on the right the modified ones.

This idea seems interesting to me, especially if there is an easy and fast way to navigate between the two editors. Maybe with tab and shift + tab.
Another thing that might help a lot would be a shortcut to copy what's left to right.

[isidorn]

@ajborka this should be it https://code.visualstudio.com/docs/getstarted/settings
Though that is just generated from our default settings page with all the descriptions.
@jvesouza makes sense.

[ajborka]

@isidorn I will take a look at it later today. @jvesouza has an interesting idea. I would add to it that when scrolling through either editor, the oposite side keeps in sync with the other. For example, when I scroll to editor.cursor.blink in the defaults, the matching setting is also selected in the modified pane. Likewise, if I select editor.accessibility in the modified, it should select it in the defaults. A keyboard shortcut to switch between defaults/modified would be a good idea. I recommend f6 if vscode doesn't already use it.

[isidorn]

@ajborka sync scrolling is actually how our original settings editor from a couple of years ago looked like. We could potentially revivie it.

[ajborka]

@isidorn I would want some use case scenarios for testing before putting it back in if vscode removed it. It's worth looking into though.

[roblourens]

I think that everything here is addressed by the work this summer or covered in other issues.