Improve settings editor accessibility

[roblourens]

Issues about the accessibility of the settings editor UI have come up a few times, and I'd like to collect more info about how and whether screenreader users are using it, what issues they are having, and how it could be made to work better.

• Is the document structure of the settings editor easy to understand and navigate around?
• Can users navigate to different setting categories, search for particular settings, or browse through the list efficiently?
• Can setting names, descriptions, and values be read consistently?
• Does editing different types work well?
• Does the JSON editor work well for settings that have to be edited that way?
• Does the JSON editor in general work better for screenreader users than the UI?
  • If so, should it be the default? If not, would it be possible to make that the case?

A few issues with discussions about settings editor accessibility:

• Screen reader users have a difficult time navigating the settings pane #92485
  • Mentions that tab navigation in the virtualized list doesn't work well. We suggest using JSON editor
• Orca fails to reliably speak the settings tree #92488
  • Bug with orca not speaking categories
• Settings scope toolbar accessibility #71952
  • Wrong screenreader mode while editing
• Keyboard navigation in settings editor is broken #66237
  • Keyboard navigation issues (page down, spacebar aren't supported) and discussion about row selection
• Screen Reader Cannot Tell If Changing User Or Workspace Settings #97068
  • The setting scope tabs do not have proper aria attributes
• Accessibility: Provide better user interface for the settings screen #94525
  • Difficulty understanding the relationship between the "table of contents" tree and the position in the settings list. Pointing out VS, Chrome, and FF as better examples.

[roblourens]

Got some great feedback in today's call, thanks for everyone who joined. I will flesh out my notes after I listen to the recording but here are some quick notes

• People would prefer to use the settings GUI editor - the JSON editor is necessary but we can't rely on it to be the sole "accessible option"
• People get lost in the page structure, it's not clear how the category list relates to the settings list on the right
• You can tab from the category list to the setting list, but you can't tab back
  • You are stuck shift+tabbing to the top of a long list, and also focus is trapped on the focus sink at the top of the list (bug, there is an issue for this)
• There is no indication when you have tabbed across a category boundary, you are just tabbing through settings forever, and this is very confusing and unexpected
• Proposal that seemed generally popular: instead of showing an extremely long virtualized settings list on the right, show a shorter non-virtualized list which is only scoped to the selected category on the left. This would mean that tabbing could work more normally, and other navigation modes like "browse mode" in NVDA should work as expected. This would make the settings editor work more like a typical form.
  • Another advantage of this - if the content is not virtualized, it would be easier to make page up/down/spacebar work normally on this page, since the browser would scroll it the same as any other normal content that overflows the page viewport.
• Another proposal: make settings rows selectable, making the settings list work more like a typical list. Navigate using arrow keys, maybe left/right to go between the category list and the settings list.

[alex19EP]

ok. lets summarize. 📒

main points

• settings shouldn't be an endless list.
  • need to limit them to one category.
• It should be impossible to switch to another category from the settings, only from the list of categories.

settings navigation

at the call, opinions were divided. I will speak for myself.

• Navigation in the settings list should be done with arrows. the tab should go to the setting or button wich relates to current setting.

[alex19EP]

oh @roblourens was faster than me. ☺

[webczat]

Generally the arrow navigation proposal is not typical as in, for me the typical workflow is using tabs. On the other hand I don't think the idea with exposing settings as an arrowable list is necessarily a bad idea, but different and not sure if obvious to someone new. At least it shouldn't be confusing.

[alex19EP]

@webczat i think arrows will be cool because in code settings we have not only settings but for example changed indicator or button with copy json or clear actions.

[webczat]

actually makes sense. currently we can't tab to more actions, we have to shift+f9 or use browse mode. maybe that's really better.

[roblourens]

I think the arrow key model would be confusing and non-standard - we actually used this model in an early version of the settings editor, and it got bad reviews. I think it's confusing to pick a setting with the arrow keys, then tab into that setting, but then in that context, the arrow keys have different behaviors, for example they will move the cursor around in an input box or expand a dropdown. Then to pick the next setting, you have to tab out of there, back to the setting level, then use arrow keys, and so on. This is just not a typical interaction model and I don't think I've seen something like that before.

To me, the settings editor is fundamentally a form and it will be easiest for new users to understand if it can be navigated like other forms.

[webczat]

maybe, although I could live with this. vscode does have some nonstandard behaviors here and there and I know I would not have problem with this one, so I'm open to both ways. :)

[alex19EP]

I think it's confusing to pick a setting with the arrow keys, then tab into that setting,

we can use enter for that. tab will be move to settings button menu.

I think the navigation using the arrows will be faster.
tab and shift tab will move you to category and settings trees, setting button menu. and such.
in this way we show the overall composition of this window.

also do not forget that the list of settings can be quite long.

[isidorn]

@roblourens is it an easy change to change the settings tree to use the arrow key model? If yes, maybe you can just produce a build so we can try it out and provide feedback. If you got reference to those bad reviews from before that might also be helpful as I might be missing something which our users hated with this arrow model.

[roblourens]

I think it would take some effort to get it right. I am mainly just thinking of internal feedback in the UX call and offline. There was this issue: #54039 but it doesn't capture everything.

@alex19EP I didn't fully get your point here:

i think arrows will be cool because in code settings we have not only settings but for example changed indicator or button with copy json or clear actions.

How do those other things relate to the arrows?

[alex19EP]

How do those other things relate to the arrows?

I think that it would be more logical to move to this button using the tab. I hope it’s clear now.

[roblourens]

I understand why this scheme would have some benefits, but I think that what really bugs me is the idea that a new user would see this page which looks like a normal form with input boxes and dropdowns and things, and not be able to tab to those things, like they can pretty much 100% of the time in other places. Instead they try to tab, fail, then have to discover this new way of interacting with the page.

[isidorn]

@roblourens thanks for thinking about this. Here's a practical idea, just as food for thought:
Keep current tab behavior in general so existing users are not broken.
Just change Arrow behavior. Here's how the arrow behavior would be:

• Up / down to navigate through elements.
• Space / enter to "move inside the element"
• Once you are inside the element up/down are specific to the element, thus they do not navigate top level
• once you are inside the element: esc to move outside of the element
• While focus outside of the element typing characters searches and filters

[roblourens]

Maybe we can experiment with it but I guess it feels like we are reinventing something that a screenreader should help users do already, and if I understood screenreaders better, I would know how this "should" work without creating a new control scheme.

[jhomme]

I think it's confusing to pick a setting with the arrow keys, then tab into that setting,

we can use enter for that. tab will be move to settings button menu.

I think the navigation using the arrows will be faster.
tab and shift tab will move you to category and settings trees, setting button menu. and such.
in this way we show the overall composition of this window.

also do not forget that the list of settings can be quite long.

Is this something like File > Options in Microsoft Office? if so, it is workable.

[isidorn]

@roblourens do we plan to look into this in May? I think we should push it out to June?

[isidorn]

Unassignig myself for now. @roblourens let me know how I can best help here.

[9at8]

Sorry for the delay!

Here's the build for the pagination version. There should be "Next" and "Previous" buttons at the bottom of the page if there are more settings available. Currently, the page size is set to 20, but we can change it if you think that would be better. Search is working in this build, so let me know if you have any feedback for that as well. Search is also an excellent place to try out pagination. Try using words that would yield a lot of results as a search query; for example: "a", "the", etc

Windows x64: https://az764295.vo.msecnd.net/insider/656350171fed8b830b4b73e9cf48068f67e11697/VSCode-win32-x64-1.48.0-insider.zip

macOS x64: https://az764295.vo.msecnd.net/insider/656350171fed8b830b4b73e9cf48068f67e11697/VSCode-darwin-insider.zip

Linux x64: https://az764295.vo.msecnd.net/insider/656350171fed8b830b4b73e9cf48068f67e11697/code-insider-1595353470.tar.gz

[9at8]

Sometimes the links to get more information about a feature come before a field and sometimes after. Make this placement consistent, but I prefer after.

@jhomme @alex19EP I don't think I understand this correctly. Can you give me an example of where this happens?

I agree that we need a way to quickly move focus to the settings categories, but I'm not sure if it should be the f6 key.

We do have a keybinding that you can configure for that, but it doesn't have a default. If you open up "Preferences: Open Keyboard Shortcuts" from the command palette, and search for settings.action.focusTOC you should be able to configure it. Although, I would like to get recommendations for a default keybinding as well.

i tried that but didn't succeed. maybe I didn't understand something. @9at8 can you explain in more detail?

I was wrong about the Up and Down arrow keys, but if you are using browse mode, you should be able to use Page up and Page down to navigate the page now.

[9at8]

Here are the builds for the settings editor with a load more button in the bottom, instead of pagination controls. At the end of the settings page, you can find the "Load more settings" button if there are more settings on the page. As before, Search is working in this build.

Windows x64: https://az764295.vo.msecnd.net/insider/56dd03117ff0524f6d6dda642836b7d085438fad/VSCode-win32-x64-1.48.0-insider.zip

macOS x64: https://az764295.vo.msecnd.net/insider/56dd03117ff0524f6d6dda642836b7d085438fad/VSCode-darwin-insider.zip

Linux x64: https://az764295.vo.msecnd.net/insider/56dd03117ff0524f6d6dda642836b7d085438fad/code-insider-1595441406.tar.gz

[jhomme]

Hi,
These observations may not answer the questions we are considering, but I wanted to list them here. These are all observed with NVDA, the newest release candidate build, which has improved responsiveness.

• Open Settings and navigate to Commonly Used.
• Tab once and you land on a link. Tab again, and you land on Files Autosave. Tab again and you land on another link. These two links, or seemingly 2 links, lead to the same place. I feel that the first one should not be there or that we should not be able to land on it.
• The other thing that happens here is that the longer description about getting more information about the setting is spoken when focus is on the combobox that allows the user to change the setting, rather than the link. You can't get information about the setting by pressing ENTER on the combobox. You have to hit it on a link.
• I noticed that if you change a setting, such as Files AutoSave and then press ENTER, you get reliable focus behavior. If you change a setting and hit TAB, focus lands lands at the top of the document and with the latest NVDA, Browse mode turns on. The Browse mode behavior is probably due to NVDA changing so that it does not automatically go into Application mode when VS Code runs. When you switch into Application mode with INSERT+SPACE, NVDA reports that focus is at the document level. If you then tab, you land back on the tree view.
• The behavior I expect is that if you tab, you should land on the next item in the order of the things to change, which in this case would be the second link, as I was talking about above.
• Another observed behavior is that any time I change a setting and press ENTER, I have to tab all the way through until I get back to where I left off. focus should probably return to the item I changed, so that I can quickly verify that I have made the correct change. I feel that it should be OK to have focus move to the next item when I change it and press TAB. It would be disconcerting to press TAB and have focus stay where it is.
• An example of the link about a setting coming before the setting is the one about Editor Multicursor Modifier. I again feel that you should encounter the setting, then the Read more link.
• When changing a setting, it would be a very nice thing to have if the editor would report that the setting you land on is the default. It reports that the setting is modified.

[9at8]

Tab once and you land on a link. Tab again, and you land on Files Autosave. Tab again and you land on another link. These two links, or seemingly 2 links, lead to the same place. I feel that the first one should not be there or that we should not be able to land on it.

I am experimenting with another navigation model where each setting row can be navigated using up and down arrow keys, and once you hit tab, you move focus to the control of the setting. (for example, input box, checkbox, etc) This would prevent moving focus to the links.

Another observed behavior is that any time I change a setting and press ENTER, I have to tab all the way through until I get back to where I left off. focus should probably return to the item I changed, so that I can quickly verify that I have made the correct change. I feel that it should be OK to have focus move to the next item when I change it and press TAB. It would be disconcerting to press TAB and have focus stay where it is.

So if I understand correctly, when you modify a setting and hit tab, the focus goes to the top of the document? If so, this is a known issue, and we're working on fixing it!

[jhomme]

Hi, I think you do want focus to land on the links so you can get more information if you need to. ========== Jim Homme Skype: jim.homme FreeChess: jhomme Twitter: jimhomme <https://twitter.com/jimhome> Facebook: jimhomme Website: jimhomme.com <https://www.jimhomme.com/> From: Aditya Thakral <[email protected]> Sent: Thursday, July 30, 2020 12:55 PM To: microsoft/vscode <[email protected]> Cc: Jim Homme <[email protected]>; Mention <[email protected]> Subject: Re: [microsoft/vscode] Improve settings editor accessibility (#97567) Tab once and you land on a link. Tab again, and you land on Files Autosave. Tab again and you land on another link. These two links, or seemingly 2 links, lead to the same place. I feel that the first one should not be there or that we should not be able to land on it. I am experimenting with another navigation model where each setting row can be navigated using up and down arrow keys, and once you hit tab, you move focus to the control of the setting. (for example, input box, checkbox, etc) This would prevent moving focus to the links. Another observed behavior is that any time I change a setting and press ENTER, I have to tab all the way through until I get back to where I left off. focus should probably return to the item I changed, so that I can quickly verify that I have made the correct change. I feel that it should be OK to have focus move to the next item when I change it and press TAB. It would be disconcerting to press TAB and have focus stay where it is. So if I understand correctly, when you modify a setting and hit tab, the focus goes to the top of the document? If so, this is a known issue, and we're working on fixing it! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#97567 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRUZJPAH3OIKY7OOHJGVOTR6GQVXANCNFSM4M6NXEKQ> .

[jhomme]

Hi,
I would like to encourage you to release this in the Insider edition even though it is not perfect. It is much better than before.

[roblourens]

Thanks for the feedback! We've also explored the other option, navigating the settings list more like a list, using the arrow keys, with rows that can be focused. There is a more detailed description of it in this issue: #104318 and links to builds. Would really appreciate any feedback. We will be trying this out in Insiders once we get the next release out.

[jhomme]

Hi, Can’t wait to see this. Jim

[roblourens]

Hey @alex19EP have you had a chance to try the new build in #104318 yet? This essentially implements what we discussed way back in may

[isidorn]

I really love the improvments in VS Code insiders.
Though would also love to hear @jhomme and @alex19EP feedback

[alex19EP]

I really love the improvments in VS Code insiders.
Though would also love to hear @jhomme and @alex19EP feedback

hello @isidorn pleas see my comment

[jhomme]

Hi, Thank you so much for all who worked on this. We are definitely going in a good direction now. This is better. I would like to bring up one point, though. Below is one setting that I used the NVDA log to show you. This is the accessible name property, and there is nothing in the accessible description property. The accessible name property should state what something is, while the accessible description property should say what it does. Note that I copied this exactly, and it is very verbal. Also note that we somehow get more information about the types of controls with NVDA than we do JAWS. I will start making comments on smaller points after this, but we really need to lose the repeated verbalization and we need the correct information to appear in the correct accessibility properties. name: 'editor.acceptSuggestionOnCommitCharacter Accept Suggestion On Commit Character Accept Suggestion On Commit Character. Controls whether suggestions should be accepted on commit characters. For example, in JavaScript, the semi-colon (;) can be a commit character that accepts a suggestion and t

[isidorn]

@jhomme thanks for feedback, we are glad you think this is going in the right direction.
As for the aria-label and aria-description, mostly we just use aria-label since if I am not mistaken aria-description is not yet fully supported by all screen readers. Though it would be great if you create a new issue regarding this where we can continue this discussion and involve the appropriate screen reader folks.

[jhomme]

Hi, I will test soon with NVDA and JAWS and try to create a new issue that spells out the symptoms. I will use the JAWS ability to read out what it thinks the tags and attributes are. It will take some time to write it all up. No worries, though.

…

On 9/29/20, Isidor Nikolic ***@***.***> wrote: @jhomme thanks for feedback, we are glad you think this is going in the right direction. As for the aria-label and `aria-description`, mostly we just use `aria-label` since if I am not mistaken `aria-description` is not yet fully supported by all screen readers. Though it would be great if you create a new issue regarding this where we can continue this discussion and involve the appropriate screen reader folks. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #97567 (comment)

-- ========== Jim Homme Website: https://www.jimhomme.com/ Twitter: @JimHomme Facebook: http://www.facebook.com/jimhomme LinkedIn: https://www.linkedin.com/in/jimhomme Skype: jim.homme FreeChess: jhomme