Accessibility

[bpasero]

We break Accessibility down into multiple chunks of work:

Issues labeled Accessibility

https://github.com/Microsoft/vscode/labels/accessibility

Keyboard navigation & Focus indication

• Define central CSS rules for focus indication
• Support navigation in actions and action bars
• Support navigation in tree widget and embedded actions
• Support navigation in split view and embedded actions
• Support navigation to search details toggle
• Support navigation in iframe previews
• Support navigation in feedback widget
• Support navigation in debug repl
• Support navigation in debug complex hovers
• Support navigation to sashes for resizing parts
• Don't navigate to the html of the app

Related PR: #2077

[zersiax]

Looking good so far :) I think screenreader support can be broken up into points like the following:

• Make main edit area focusable
• Enable screenreaders to receive useful information using UIA when simply arrowing through existing input and creating input (yes, yes, I know that is easier said then done with this app)
• Add UIA events for things like autocomplete suggestions, debugger warnings etc.
• See what can be reused in the initial UIA implementation for the editor to make things like preferences screens and other such dialogs speak

The action bar and its actions are already sort of usable if you know how to get to them, so those only need some minimal work to be keyboard-accessible, no additional screenreader support should be required.

[egamma]

@zersiax thanks the feedback. In the January update we will have some first rough support for accessibility including the editor (needs to be enabled through a setting). I would much appreciate if you can give it a try. I'll follow-up with more details in this issue once the update is available.

[egamma]

@zersiax the 0.10.7 insiders build is now available. There is some initial support for screen reading of the editor contents on Windows when using NVDA.

Here is the blog that describes how to get the release:
https://blogs.msdn.microsoft.com/vscode/2016/02/01/introducing-insiders-builds/

Here are the relase notes:
https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/latest.md

We would be much interested in your early feedback.

[zersiax]

Just did some quick checking. NVDA reas stuff in the code editor. Sometimes it seems NVDA thinks the line you are currently on gets selected after you've arrowed to it, leading to some strange output now and again. It makes some lines repeat with "selected" added in front to indicate selection of the entire line. This is false however since typing will not in fact delete the current line, which is good. It does lead to a bit of head-scratching for a f ew seconds though. Overall, good improvements so far :) Keep up the good work.

[bpasero]

@zersiax would also appreciate some feedback for screen reader support in areas outside the editor (views, etc.).

[bpasero]

Thanks for doing this btw 👍

[egamma]

Thanks much for trying it out and here are some more questions. We have also added additional support that should improving the screen reading. This is enabled with ALT+F1. Did you discover this support? Does it improve things.

@alexandrudima FYI.

[zersiax]

Hi,

No, I was not awareof this functionality and will try it. What I have found with it disabled is the following. Please not I am haphazardly jumping around right now, if you want me to do a systematic check please give me some areas to focus on, code is rather big 👍

• When bringing up the git view, screenreaders don't report this. When hutning around the accessibility tree, I come across a group labeled simply as 
  , which holds these git elements. This is a unicode symbol that sometimes is reported as 'note' , but doesn't seem to always work with NVDA.
• In search, when there are no results this shows up as text, but I have to go hunt for it. It would be good if this is either popped up or reported via a live region of some kind. The treeview of search results, when it comes up, is accessible and seems to work. It might be good to bring focus to the treeview after a search though.
• In the menubar, you cannot use left and right arrow keys to jump between menubar menus. Also, I can't seem to find the menubar in the accessibility tree, so I essentially don't know what menus are there. I do alt+letter now to get to the menus I am guessing are there like file, edit, view etc.

What does the alt+f1 keystroke add?

[bpasero]

git view

When you open the git view, we immediately transfer focus into the git commit text area. Would you expect this text area to explain to you that it is for committing the changes you have or even more (how many changes etc.)? Maybe you could give an example what you would expect here

search view

Good point regarding the search result message that is not being read. I will look into that. I am not sure about moving focus out of the search box, I was assuming that it is not nice to programmatically change focus without user interaction. I do agree though that it would be nice to announce the status of the search operation to the user (progress, results).

menu bar

Unfortunately the menu bar does not seem to be the native menu bar on Windows. Here we rely on the Electron framework and do not have much control.

What does the alt+f1 keystroke add?

It brings the editor into accessibility mode, so you want to enable that to test screen reader support within the editor!

[zersiax]

Git view:
Yes, I think that would be good. Right now I was actually thinking I was still in my editor document.
search:
You are right, often playing ninja with focus isn't considered as a good practice. But I think in this case it actually augments the workflow. You search to get results. It is logical to therefore go to results after doing a search, since ...where else are you going to go?

Alt+f1:
Please give me some things that work differently when this is enabled. Without screenreader mode, the editor behaves as I described in an earlier comment. When pressing alt+f1 this toolbar pops up that says I have to press shift+ctrl+r to turn the accessibility support on. Doing that does show me it is toggled on, but i don't really understand what it is supposed to do exactly. I do see something about toggling tab key behavior using ctrl+m, is that what it is supposed to do? That toggle works fine for as far as I can tell.

[zersiax]

Ok, turning on screenreader mode seems to get rid of the 'selected' thing I was talking about. Also, the search seems to be visible with its controls greyed out ('unavailable' for screenreaders), not sure why or if that's because of something I did or not.
What else should this influence, e.g., do autocomplete suggestions etc. work in this mode as well? Anything else?

[bpasero]

@zersiax the difference with Alt+F1 is that we put the entire contents of the file you are editing into the browsers textarea element. We are not doing this typically for performance reasons when the file is very large, that is why we require this explicit action. Doing so, we rely on the browser to provide the related accessibility features for a text area control with text.

I will make a pass over our views and panels to make sure that the text that is being read when switching to these things makes sense in the context where they are.

[bpasero]

@zersiax another question I had in mind is how do you explore an application when you start it for the first time without knowing its structure? do you let the screen reader read out the structure of the application? did you try that with Code already?

[zersiax]

@bpasero good :) I understand the underlying technologies of Code will make rendering an entire file to a screenreader at once in the current model almost impossible due to performance reasons, so its good you built in this toggle. When users get to this though, we wil need to somehow make them aware the toggle even exists. I now understand the whole 'selected' issue when this mode is off as well, its due to the chunk of code you're working with being rendered almost at runtime to the screenreader which slightly confuses it. This is not a showstopper though.
As for how I explore an application, typically I don't. I tend to focus on what I am trying to get done and see what I come across in the mean time. Problem with Code is the Electron framework limitations are slightly preventing me from doing that due to the fact I can't seem to see the menubar's individual menus anymore. This used to work somewhat way, way back when. When I am really looking for something I tend to use NVVDA's object navigation feature which relies on the accessibility tree that UIA or some other framework provides. Usually this gets me places faster than the individual keyboard shortcuts of an app if they don't exist or aren't implemented properly.

[bpasero]

@zersiax when you move focus into the editor, we give the screen reader a message that indicates you can press Alt+F1 to enable this mode, maybe this message was no clear enough or not read to you at all?

I will file a bug for the Menu issue on Electron and link it back here: electron/electron#4330

NVVDA's object navigation feature
How do you trigger that? I have NVDA installed too. Would like to see what it reports for Code.

[zersiax]

Hi,

Best to check the manual for object navigation, theres a clear section about it there.
As for the hotkey, no I wasn't informed this hotkey existed when opening the program. Should I have been? :)

[bpasero]

@zersiax we set the following aria-label to the editor and would expect a screen reader to read it once you focus the editor:

Text file editor.Press Alt+F1 for more info.

[zersiax]

Hi,

Best to check the manual for object navigation, theres a clear section about it there.
As for the hotkey, no I wasn't informed this hotkey existed when opening the program. Should I have been? :)
Now you mention it, yes, that is read out. However, more info may be a little too generic in this case. How about "press alt+f1 if you are using a screenreader". Since ARIA-labels only communicate with screenreaders, that way it is both clearer what you mean and not a hindrance to others who aren't using a screenreader. 'more info' could be all sorts of things, from a help page to some kind of status message. I think that confused me as well :)

[bpasero]

@alexandrudima fyi for discoverability of Alt+F1

[ahicks92]

I saw stuff on Twitter that made me pop in.
Object nav is a set of 4 or 5 keys for directly exploring the object hierarchy of the application. What exactly object hierarchy means in this case is a bit interesting, but it's not UIA. NVDA has an internal abstraction over the idea of accessibility object, and browsers are treated specially. I believe Aria can let you change this, but Aria may not be working very well in Chromium. The basic keys (on the laptop layout) are shift+nvda+the arrow keys. Left and right for previous and next object, up for go to parent, down for go to children.
When it works well and if the application is bad at providing navigation keystrokes, it can certainly be faster. When the application doesn't provide or provides insufficient keyboard support, it can be a lifesaver. I would personally expect any intermediate to advanced NVDA user (so, like, everyone who'd use VSCode) to know about and use this feature on a semi-frequent basis.
It is worth noting that Aria-label is an interesting case where it doesn't always do what you'd expect. Simply putting it on stuff will probably work here, but please please please test. I've seen so many places on the web where people are using Aria-label and it fails to be read at all for stupid reasons that nevertheless don't have good solutions (on the NVDA side of things, don't even get me started on how annoying it is that the Aria spec doesn't say what AT must do).
And finally, I don't know if it's a problem here, but I feel like it's worth mentioning. A lot of the other Visual Studio stuff and a lot of the MS installers use really bad labels in addition to the horrible accessibility on offer. To give an example which probably doesn't apply, "Git Commit Text:" is way better than "This is the git commit text" or, god forbid "Put the git commit text here." Syllable minimization is a very important thing, and I see very little attention paid to it in general and especially in other Microsoft developer products (count the "This button xx" instances in various installers, my screen reader already tells me "button" and "this" is redundant...and then the rest of the label just repeats the actual text on the button--also already read).
Keep it up. The story for good programming editors for blind programmers is Notepad++, and Notepad++ has a ton of annoying issues. Everything else is stuff by other blind people and it's all buggy, to put it kindly. Do a good job here, and the blind people will come at least.

[zersiax]

I'm going to discuss VS Code accessibility with someone at MS in a few days, I will certainly bring these points up since they are on the mark :)

[ahicks92]

Actually, while I'm thinking about it, this comment exists to mention @jcsteh. He might be interested in this, given that VSCode accessibility is the first time I can personally recall Microsoft acknowledging that NVDA exists publicly, as opposed to just saying "narrator and other assistive technology" or something to that effect.

[jcsteh]

Just some clarifications:

Object nav is a set of 4 or 5 keys for directly exploring the object hierarchy of the application. What exactly object hierarchy means in this case is a bit interesting, but it's not UIA.

In this case, it's based on MSAA/IAccessible2, since that's what Chromium exposes. However, NVDA does tweak the tree a bit, particularly if simple review is enabled (which it is by default).

NVDA has an internal abstraction over the idea of accessibility object, and browsers are treated specially.

For object nav, browsers aren't really treated specially at all. They are for browse mode, but that's an entirely different issue and I suspect irrelevant for Code.

I believe Aria can let you change this, but Aria may not be working very well in Chromium.

ARIA lets you change the hierarchy using aria-owns. This is now implemented in Chromium, though it was fairly recent; I don't know what version of Chromium you're using here.

It is worth noting that Aria-label is an interesting case where it doesn't always do what you'd expect.

When you're not dealing with browse mode and you're primarily dealing with interactive controls, aria-label should work as you expect. I'm guessing browse mode isn't used here; it certainly wouldn't make sense to do this.

[isidorn]

We have improved accessibility for debug sessions in the latest vs code alpha release which can be downloaded here:
https://az764295.vo.msecnd.net/alpha/4090a5d2ea7a84f215e7f16929a12ad76045f94d/VSCodeSetup-alpha.exe
It would be great if someone is willing to tryout the debug experience and give feedback on accessibility so we could further improve here.

[stevencl]

I spoke with @zersiax earlier today and discussed what we should do in the debugger. Here are my notes. Florian, please feel free to add or comment if I missed anything or got it wrong

1. After pressing F5 to launch the app under the debugger the debugger should announce "Debugger launched" before the app starts up and the screen reader starts announcing from the app.
2. When a breakpoint is hit, we should announce "breakpoint hit filename linenumber". If it's a conditional breakpoint, announce "conditional breakpoint hit filename linenumber". We discussed whether or not to announce the conditional expression but thought that it might be too verbose to do so.
3. Each time execution moves from one breakpoint to another, or each time a breakpoint is hit, there is a lot of text announced. The main window title is announced, followed by the file name. Then "Text file editor, press Alt+F1 for more info". We don't need to announce this each time and should focus on announcing that a breakpoint was hit.
4. Inside the debug viewlet, when browsing the list of variables we should reduce the verbosity as much as possible. For example, consider just announcing the name of the variable or field rather than prefixing it with "variable"

[isidorn]

Great feedback, thanks a lot. I'll try to improve these next week
Created #3009

[zersiax]

Hi, Just saw the new release changelog, good work so far. I want to stress-test the system a little. See where accessibility is still not optimal and create issues for the stuff i find. Please let me know a fitting strategy for this? Is there a tag I should group them under, put them all in one issue or ...?

[bpasero]

@zersiax thanks much for willing to help! we will soon release a new insider drop with all our changes that you can use.

We typically file individual issues here around accessibility with the label "accessibility". We will take care of the triaging from then on!

[bpasero]

@zersiax actually I think the insiders build (0.10.10-insiders) is already out!

[bpasero]

Lets continue accessibility work via issues reported. Closing this one.