The official source of product insight from the Visual Studio Engineering Team
Microsoft as a whole is committed to making our technology accessible to everyone (see our Accessibility Mission Statement). This is true for us here in Visual Studio as well, and we work continuously to improve the accessibility of each product we release. The recently released Visual Studio 2013 is our most accessible version yet.
In all versions of Visual Studio, our designers routinely consider a number of areas related to accessibility when designing a new UI. Some such areas are:
In alignment with our goal to make each release of Visual Studio perceptively better than the previous versions, we have been collecting feedback from our customers through Microsoft Connect, Customer Support Services and internal feedback systems. From these sources, three primary themes emerged related to our accessibility: screen reader compatibility, contrast ratios, and keyboard shortcut documentation. In this post, I’d like to share some updates in each of these three areas.
According to the most recent WebAIM Screen Reader User Survey, Freedom Scientific’s JAWS is the primary screen reader in use around the world. With this in mind, as well as to maintain compatibility with Microsoft’s screen reader Windows Narrator, our development teams made an extensive investment to ensure that Visual Studio 2013 is compatible with Windows Narrator and JAWS.
Feedback also indicated there wasn’t enough differentiation between the colors we chose in the new Visual Studio color themes. In Visual Studio 2013, we increased the contrast ratio in our primary code editor in the blue, dark, and light themes as well as in the High Contrast modes. Fonts and colors are still fully customizable via the Tools/Options dialog, and can be further customized by using the recently released Color Theme Editor for Visual Studio 2013 which is an extension allowing maximum control over colors.
The Visual Studio documentation has been updated to include keyboard shortcuts for core Visual Studio 2013 features. Here are links to these documents:
We are already planning work on the next version of Visual Studio and are interested in hearing about the issues that impact developers the most. Please share your thoughts on our product’s accessibility as comments below, via the Send-a-Smile feature from within the Visual Studio 2013 IDE, or via User Voice. If you have come across a bug, you can log it through the Visual Studio Connect forum.
Thank you for helping us make Visual Studio more accessible!
very interesting and useful
"our goal to make each release of Visual Studio perceptively better than the previous versions"
If this is truly your goal, you are failing. You don't need to look any further than the horrible flat UI, the removal of setup projects, and the necessity to use extensions to get basic functionality.
I am a user of Jaws and NVDA. Narrator is still too far behind to be used productively.
My experiences with VS are mixed. Certainly some progress has been made but there are still:
1. Unlabeled controls, such as links and buttons. Like in the Test Explorer of VS 2012.
2. Lack of consistency of keyboard shortcuts between VS and other Windows apps.
For example, in Win32 apps links and link-like buttons can be activatedboth using space and enter. In VS, only enter works.
I think that the problem is the use of WPF. Since WPF is a redesigned UI framework for Windows, the developers forgot to implement one hundred percent of the keyboard affordances that where implemented back in the Win 95 days for Win32 apps. So, since VS uses WPF, it inherits all its accessibility errors.
Please check, using appropriate testing infrastructure, that:
A) All WPF controls implement the same keyboard shortcuts as their equivalent Win32 ones.
B) That tab and shift+tab work all the time and consistently. Sometime tab might work and shift+tab not, or tab might cycle through all controls but shift+tab skip some.
C) Same for ctrl+tab and ctrl+shift+tab, ctrl+page up and ctrl+page down, f6 and shift+f6. Sometimes f6 works and shift+f6 does not for all panels.
3. Confusing shortcut keys:
Ctrl+k,ctrl+d. Don't you think that these long key sequences are hard to press and difficult to remember?
Also, most times, they make no sense mnemonically.
Plus, there are multiple keyboard schemes, so you can't just learn one scheme and be done with it.
The C# key bindings though are somewhat easier to press, because they drop the Ctrl from the second key sequence.
4. Hard to find and unintuitive shortcut keys:
If you are in Solutions Explorer, or in any other tool window for that matter, how do you bring up its associated toolbar of commands, like "Show All Files"?
Nobody knows. Until one day you discover that you need to press shift+alt.
Not alt+shift, that is used for changing the language. But shift+alt. And with Jaws it seems that you have to press it in a very specific way, i.e. with some delay between the keys, because it wouldn't work otherwise.
Also, say you are in the Debug > Exceptions dialog and are trying to change the first chance exceptions to be caught. There are two check boxes for each exception in that dialog. How do you press each one if you have only space to work with?
Well, there is a way. But it's not intuitive at all. I can't even remember it. I always have to ask a colleague to do it for me.
5. I desperately want shortcuts for jumping to the next / previous method / function. How hard is to implement this. I have been wanting it for 15 years now.
6. Keyboard bugs that are never fixed. I think that you don't have any tests that catch keyboard bugs.
Go to the Output window.
Press tab to get onto some window-specific otpions.
Try to switch to the Solutions Explorer or any other window.
You can't. You are just stuck there.
7. Work with Jaws to fix their bugs too. Jaws began saying "Normal text" or something whenever it feels like it. You cursor up and down through your code "normal text" and it starts "normal text" sprinkling this "normal text" phrase randomly at you ... "normal text" while reading your code.
Plus, it modifies VS settings behind your back to make VS more accessible? What? Which settings? Why?
It just pops up a message saying: "We have modified VS settings to make it more accessible." "OK"
You have no right to know.
By the way, I forgot to say that the sign in page where you enter your Microsoft account info in order to get or renew your Windows 8 Developer License in VS 2012, is inaccessible. I always need sighted assistance for someone to actually click in the e-mail address field, so that I can sign in. So, effectively on Windows 8 and using VS 2012, I can't develop Win 8 modern apps without sighted help.
Thank you for your feedback on your experience using VS with a screen reader. I would like to chat with you offline to get further details. Please email me mailto:email@example.com
I'm also a blind programmer; as an attempt to establish credibility, I hereby link my github page: http://github.com/camlorn/ (I do this not to self-advertise, but to establish credibility as someone who knows what they're talking about. I'm sure you guys get a lot of people who do not.). I am a user of NVDA.
Firstly, testing with NVDA is probably a good idea. Many of us technical blind people prefer it, as Jaws and Window-eyes have a lot of strange issues and crashes these days, and both provide a markedly inferior web browsing experience. I personally know several other programmers, including one who makes a living by running his own programming company, who would agree with this statement. In addition, NVDA is more spec, and tries to use UIA and IAccessible before dropping to display hooking and mirror display drivers.
Secondly, I also must agree with the useability issues. I would not use Visual Studio 2013 as my primary development environment, and the reason for this is accessibility. I want to; I cannot. My interests include C++ and GPGPU. Visual Studio's debugger would be incredibly helpful. Unfortunately, these panels are not even visible through accessibility APIs. I have not yet taken the accessibility testing tools included with the Windows SDK to Visual Studio 2013, but can report that they could not see the panels as of visual studio 2012. As NVDA reports exactly the same information internally for Visual Studio 2013, I am assuming that this has not changed, but intend to take the tools to it before reporting officially (if I can, which may not be possible due to accessibility issues; I haven't tried).
I agree with everything Nektar said. I would like to add that NVDA is unable to see any style information in the editor, and that I believe Jaws to be getting breakpoint location information through custom scripts. Both of these points should somehow be fixable, really.
I will be graduating with my Computer Science degree next spring. I must regrettably tell any employer that I cannot program effectively for the Microsoft stack. There are no command line alternatives for the IDE's advanced components, and the IDE is not in a state where I can have any real productivity with it. I have been using Cdb for the C/C++ components of my software for about a year now because of this, but it can't debug basically half the world (C++ STL, Direct Compute Shaders come to mind, but I still haven't figured out how to call C++ functions with it despite it being technically possible. Forget usefully debugging an exception).
There are two other issues that I know of at the moment, but I don't want to comment on them until I have time to take the accessibility testing tools to it. One of them may also be fixed.
For a technical discussion of the accessibility of the debugger in 2012, as well as other issues, see: community.nvda-project.org/.../3030 Disclaimer: I was involved in that discussion under the username camlorn.