Listboxes don't read with NVDA in visual studio 2012

[nvaccessAuto]

Reported by falinn.onda on 2013-02-28 21:29
Hi,
I'm trying to debug with NVDA 2012.3.1 and visual studio 2012.
There are many important windows in debug view which I'm not able to read with NVDA using keyboard (see list below).

For example assume we do the following:run in debug view and when stopping in a breakpoints move the focus to "watch" window (CTRL+ALT+W, 1) after adding watch (context menu, add watch). In this case the focus is in the watch window but NVDA doesn't report the current line/item by NVDA+uparrow or NVDA+TAB or even with flat review/object navigation. moving with the arrows in the list doesn't read the watch list content.
If the mouse is placed on the item it does read the content.
However, when i press NVDA+numpadDivide to bring the mouse to focus it moves the mouse to incorrect location.
Using NVDA+uparrow says "blank" and NVDA+TAB says "watch 1" which is the name of the window.

This unfortunate situation repeats in the following windows:
locals, call stack, quick watch etc...

If I'm missing something and there is a way to work with VS2012 debugger (watches and similar), please let me know.
Help will be greatly appreciated.

[nvaccessAuto]

Comment 1 by camlorn on 2013-04-15 21:13
I can second this. It also occurs in the window that appears if you do ctrl+tab, and a lot of other places. I'd like to see if someone could at least look at this; I'm working on a computer science degree, and the university will probably require us to use Visual Studio 2012 soon. At the moment, it's possible to compile code, but if I just wanted to compile code I'd go to command line (or eclipse, but you don't have the option to go to eclipse in the real world for windows development). Companies will probably start using it soon, so all us programmers are going to soon have problems.
Someone please, please, look into this and at least determine if this is an NVDA or Microsoft problem.

[nvaccessAuto]

Comment 2 by camlorn on 2013-04-15 21:15
O, and because I'm an idiot and forgot to say: I'm on development snapshot main-5986. I've updated the ticket version accordingly.

[nvaccessAuto]

Comment 3 by camlorn on 2013-05-05 03:56
I just looked at this again, and intend to use the UIAutomation event watcher on it tomorrow, but it does appear to be exposing the information correctly. I've changed the summary to match the larger issue, that is listboxes not working in Visual Studio, and ahve included the developer iinfo below. One oddity is that object navigation does work on it and has an effect in the application; using object navigation visibly changes which listitem is selected.
To quickly get to a test case, launch visual studio 2012 and press ctrl+tab.

Developer info for navigator object:
name: u'Team Explorer - Home'
role: ROLE_LISTITEM
states: STATE_FOCUSED, STATE_SELECTED
isFocusable: False
hasFocus: True
Python object: <NVDAObjects.IAccessible.IAccessible object at 0x06576270>
Python class mro: (<class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: u'Team Explorer - Home'
location: (460, 518, 175, 16)
value: None
appModule: <'devenv' (appName u'devenv', process ID 3036) at address 6f1fbf0>
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 16778508
windowClassName: u'ToolWindowSelect'
windowControlID: 0
windowStyle: -1811939328
windowThreadID: 6168
windowText: u''
displayText: u'Team Explorer - Home '
IAccessibleObject: <POINTER(IAccessible) ptr=0xa8525d0 at 69d5850>
IAccessibleChildID: 6
IAccessible event parameters: windowHandle=16778508, objectID=None, childID=6
IAccessible accName: u'Team Explorer - Home'
IAccessible accRole: ROLE_SYSTEM_LISTITEM
IAccessible accState: STATE_SYSTEM_SELECTED, STATE_SYSTEM_FOCUSED, STATE_SYSTEM_VALID (6)
IAccessible accDescription: u'Team Explorer - Home'
IAccessible accValue: exception: (-2147352573, 'Member not found.', (None, None, None, 0, None))

[nvaccessAuto]

Comment 4 by camlorn on 2013-05-05 03:57
Changes:
Changed title from "Visual studio 2012 problem reading windows" to "Listboxes don't read with NVDA in visual studio 2012"

[nvaccessAuto]

Comment 5 by jteh (in reply to comment 3) on 2013-05-05 10:29
Replying to camlorn:

ahve included the developer iinfo below.

I suspect the issue is that the control is reporting that it isn't focusable:

isFocusable: False

That is quite incorrect. We aren't filtering that out, but if I remember correctly, we've seen a case of the UI Automation client API doing this in the past. I'm not sure if we can work around this.

One oddity is that object navigation does work on it and has an effect in the application; using object navigation visibly changes which listitem is selected.

That sounds like broken UIA implementaition in Visual Studio to me and there's probably nothing we can do about it.

[nvaccessAuto]

Comment 6 by camlorn on 2013-05-05 17:45
It probably is. At this point, I'm almost certain it is. Fortunately, I don't need this now; unfortunately, I will need this sometime in the next year when the university switches to it from 2010.
I'm assuming someone needs to file an issue with Microsoft, if we can figure out what's going on. Is there anything else I should check, as I've already got the quite large program installed on my system?

[nvaccessAuto]

Comment 7 by camlorn on 2013-05-22 01:30
I'd love to see this resolved, one way or another, for 2013.2.
Should this perhaps be moved to a general support for visual studio 2012 ticket? I'm sure there's other problems and that it probably will require opening tickets with Microsoft, as 2012 uses a bunch of custom GUI stuff, and this is probably broken UIA on their end.
I'm wanting this more and more lately, for the simple fact that Microsoft doesn't provide a good command line debugger, the ability to use WPF, and the ability to use Sapi. I'd say it's important to me, though I don't know how many others will want/need this soon.

[nvaccessAuto]

Comment 8 by jteh on 2013-05-22 01:46
Specific tickets are much easier to handle, as it's much easier to qualify what needs to be done.

As much as we'd like everything fixed, it's difficult for us to justify devoting resources to this now, as it affects a relatively small number of users, I'm pretty certain this is a Microsoft issue and following it through is likely to consume a lot of time. I've also never personally seen an accessibility fix get into a Microsoft product except in major versions, which leads me to think the likelihood of getting this fixed for 2012 is quite low, but that's purely anecdotal. That said, I'm happy for anyone to investigate this and a patch that fixes it without breaking other things is of course very welcome.

[nvaccessAuto]

Comment 9 by camlorn on 2013-05-25 19:28
I've done more investigating, and this has entered extremely complex territory. It appears that Microsoft is not exposing accessibility information for a great deal of things, and each case is in fact unique. This ticket itself should probably be split into about 10 or so, as each problem I can find is different; they all seem to be related to listboxes, but the listboxes themselves all seem different from each other in terms of what's provided. Ctrl+tab can be read in a roundabout way; most others don't even seem to be exposing their children, or not in a way that NVDA is seeing. If I can figure out how to prove broken UIA to Microsoft, I'll try reporting this on their end; the new update structure used in 2012 does provide at least a bit of hope of seeing fixes.
This makes me sad, but as was said above, I'm one of the few this affects. Even so: this is my chosen profession, and I will have to be able to work with Microsoft's IDEs when I enter the workforce; the college has to accommodate me, but it, too, will switch eventually. At such time, it will become a problem for me there as well. I can't really make an objective counterargument to get this higher priority, however, only a subjective one.

[nvaccessAuto]

Comment 10 by jteh on 2013-05-28 05:08
You could try testing with Narrator (as painful as that is), as well as testing tools like Inspect and Accessible Event Watcher. See this MSDN article about accessibility testing tools regarding the latter two.

To make things more confusing, Narrator uses the managed API because it's written in .net, whereas NVDA uses the unmanaged UI Automation Client API because it's not .net. The behaviour of these two APIs is sometimes a bit different and there are some very annoying bugs in the latter.

[nvaccessAuto]

Comment 11 by camlorn on 2013-07-01 19:59
Just to add:
This is also a Visual Studio 2010 issue. Microsoft is not exposing the information in any form that inspect or event watcher can see, at least when I do it; perhaps it is my inexperience, but as far as I can tell, the information is just not present at all. I suspect jaws grabs it via mirror display drivers.

[nvaccessAuto]

Comment 12 by jteh on 2013-07-03 03:47
If JAWS is using its video intercept, it's possible the same can be done with NVDA's display hooking. Try accessing the text with flat review (called screen review if you're using next).

[jsschultz]

@jcsteh @camlorn, the issue where the Autos, Locals, Watch, Quickwatch, and call stack windows are not being read by NVDA was on Microsoft's end and have been fixed in the latest release of Visual Studio 2017 RC. No more need to special case those windows :)

[feerrenrut]

Considering there is an open pull request, I think this issue should be looked at more closely. At least to make a plan on how to integrate and test the changes. While it sounds like this issue is fixed in Visual Studio 2017, there may be people still stuck working with earlier versions.

[LeonarddeR]

Visual Studio 2012 has been superseded by 2013, 2015, 2017 and 2019. Given its age and the difficulty to maintain support for all these versions of Visual Studio, I'm closing this.