Visual Studio IntelliSense overly verbose

[adincebic]

To reproduce this issue:

1. I created a console application
2. In the main method I started typing "Console" and it reads ok
3. When I press "." to access "WriteLine" or other method it reads the whole line. Which gets very confusing and anoying when lines get longer. Imagine pressing up or down arrows and for each item in the Intelli sense it repeats the whole line of code and lastly reads the item in the IntelliSense. For example, if the line is following: string name = string.format("Hello {0}", textField.text);

When I got to the point when I type "textField" and than "." it will repeat the whole line and than read the "text" property, and it repeats if I move up or down using arrow keys.

It is worth mentioning that this issue is not present when using Freedom scientific JAWS, but NVDA is much better choice for blind developers.

I also reported this issue to the Microsoft: https://developercommunity.visualstudio.com/content/problem/164719/nvda-screen-reader-is-not-working-properly-with-in.html

[dyaminigo]

I confirm the existence of this problem. The impossibility of a normal view of the options in the IntelliSense list is very frustrating and, in some cases, slows down the development process. I would like the developers of NVDA to take the problem into account and fix it.

[AmadeusW]

I work on the Visual Studio's Editor team, and we provide the IntelliSense UI. I'd be happy to work with NVDA developers to prevent it from reading the entire line.

To give you more context on how IntelliSense narration works: IntelliSense completion is a tricky piece of UI because it appears in a popup window, pretends that it has focus, yet the editor in the background has actual focus: you can type into the editor and invoke all kinds of VS behaviors. The narration for IntelliSense is provided by LiveTextBlock, an invisible Text Block which has LiveSettingProperty set to Assertive (2)

Here is the relevant event from AccViewer which causes NVDA to read out the value of Name

UIA:PropertyEvent   [Name = "args. 15 of 516. Available filters: Locals and parameters (Alt+L), Snippets (Alt+T), Classes (Alt+C), Delegates (Alt+D), Structures (Alt+S), Namespaces (Alt+N), Keywords (Alt+K), Enums (Alt+E), Methods (Alt+M), Interfaces (Alt+I)"] Sender: ControlType:UIA_TextControlTypeId (0xC364), Name:"args. 15 of 516. Available filters: Locals and parameters (Alt+L), Snippets (Alt+T), Classes (Alt+C), Delegates (Alt+D), Structures (Alt+S), Namespaces (Alt+N), Keywords (Alt+K), Enums (Alt+E), Methods (Alt+M), Interfaces (Alt+I)", HelpText:"", ItemStatus:""

And here is output from the Inspect tool which summarizes all automation properties of this text block:

How found:  Selected from tree...
Name:   "args. 15 of 516. Available filters: Locals and parameters (Alt+L), Snippets (Alt+T), Classes (Alt+C), Delegates (Alt+D), Structures (Alt+S), Namespaces (Alt+N), Keywords (Alt+K), Enums (Alt+E), Methods (Alt+M), Interfaces (Alt+I)"
ControlType:    UIA_TextControlTypeId (0xC364)
LocalizedControlType:   "text"
IsEnabled:  true
IsOffscreen:    true
IsKeyboardFocusable:    false
HasKeyboardFocus:   false
AcceleratorKey: ""
AccessKey:  ""
ProcessId:  22888
RuntimeId:  [7.5968.202F348]
AutomationId:   ""
FrameworkId:    "WPF"
ClassName:  "LiveTextBlock"
IsControlElement:   true
IsContentElement:   true
ProviderDescription:    "[pid:22888,providerId:0x0 Main(parent link):Unidentified Provider (managed:MS.Internal.Automation.ElementProxy, PresentationCore, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)]"
IsPeripheral:   false
LiveSettingProperty:    Assertive (2)
IsPassword: false
ItemStatus: ""
ItemType:   ""
IsRequiredForForm:  false
HelpText:   ""
ClickablePoint: {x:-2147483648 y:-2147483648}
Orientation:    0
IsAnnotationPatternAvailable:   false
IsDragPatternAvailable: false
IsDockPatternAvailable: false
IsDropTargetPatternAvailable:   false
IsExpandCollapsePatternAvailable:   false
IsGridItemPatternAvailable: false
IsGridPatternAvailable: false
IsInvokePatternAvailable:   false
IsItemContainerPatternAvailable:    false
IsLegacyIAccessiblePatternAvailable:    false
IsMultipleViewPatternAvailable: false
IsObjectModelPatternAvailable:  false
IsRangeValuePatternAvailable:   false
IsScrollItemPatternAvailable:   false
IsScrollPatternAvailable:   false
IsSelectionItemPatternAvailable:    false
IsSelectionPatternAvailable:    false
IsSpreadsheetItemPatternAvailable:  false
IsSpreadsheetPatternAvailable:  false
IsStylesPatternAvailable:   false
IsSynchronizedInputPatternAvailable:    true
IsTableItemPatternAvailable:    false
IsTablePatternAvailable:    false
IsTextChildPatternAvailable:    false
IsTextEditPatternAvailable: false
IsTextPatternAvailable: false
IsTextPattern2Available:    false
IsTogglePatternAvailable:   false
IsTransformPatternAvailable:    false
IsTransform2PatternAvailable:   false
IsValuePatternAvailable:    false
IsVirtualizedItemPatternAvailable:  false
IsWindowPatternAvailable:   false
IsCustomNavigationPatternAvailable: false
IsSelectionPattern2Available:   false
FirstChild: [null]
LastChild:  [null]
Next:   [null]
Previous:   "" list view
Other Props:    Object has no additional properties
Children:   Container has no children
Ancestors:  "" custom
    "" window
    [ No Parent ]

to NVDA developers: we noticed that sometimes NVDA gets in a loop of repeating the contents of this text block. We'd like to work towards resolving this issue as well.

If I miss a github notification, please shoot me an email at amwieczo@microsoft.com

[josephsl]

Hi,

If this is a UIA text block, then Windows 10 App Essentials add-on will log this as well (if NVDA is restarted with debug logging enabled).

Info from NVDA side: the flow described above corresponds to name change event in NVDA. Essentially, the app module for Visual Studio (which ships with NVDA) will need to provide a handler for this event. This handler will need to identify the object in question, announce object label (name), and pass this onto other handlers.

A few things to consider:

1. Have you considered adding an easily identifiable automation ID to this text? This helps NVDA and other screen readers identify this text easily.
2. Have you considered splitting this text into at least two parts (two elements)? Right now, even if we can identify the element/object from UIA tree, it is very verbose.
3. Have you considered employing controller for event? This will then allow NVDA and Narrator to treat IntelliSense list as an auto-suggest control. This will work properly if controller for property does return IntelliSense list, and the one we wish to use is selected automatically and actually shows up as selected to UIA clients.
4. If controller for event doesn't work, how about asking Windows Shell team to let you borrow the logic used for hardware keyboard input suggestions? This may involve redesigning the accessibility representation of IntelliSense suggestions as a list control, thereby allowing arrow keys to be used to navigate between suggestions.

Thanks.

CC @MichaelDCurran

[Adriani90]

cc: @francipvb, @mohammad-suliman your thoughts are also very apreciated here. Thanks!

[francipvb]

Hi,

If this is a UIA text block, then Windows 10 App Essentials add-on will log this as well (if NVDA is restarted with debug logging enabled).

Info from NVDA side: the flow described above corresponds to name change event in NVDA. Essentially, the app module for Visual Studio (which ships with NVDA) will need to provide a handler for this event. This handler will need to identify the object in question, announce object label (name), and pass this onto other handlers.

A few things to consider:

1. Have you considered adding an easily identifiable automation ID to this text? This helps NVDA and other screen readers identify this text easily.

It is easily identifiable by NVDA right now, at least in Visual Studio 2017 and 2019.

Well, casually I have a script for intellicense at code editor, but it only interrupts speech and call to reportFocus but in a list item, not the label. This approach have some problems, anyway.

For the label, event_liveRegionChanged is called too late in some situations, but it occurs also on other parts of visual studio and other events while running background tasks such restoring or parsing code.

I didn't tried to use nameChange event at all...

I tried to use the caret event to avoid speech and braille output while intellicense menu is open, but it is not called at all for UIA text edit controls.

[AmadeusW]

How do we prevent NVDA from reading the entire line of code? Currently, when intellisense popup appears, we raise AutomationEvents.MenuOpened event, and when it closes, we raise AutomationEvents.MenuClosed.

Have you considered adding an easily identifiable automation ID to this text? This helps NVDA and other screen readers identify this text easily. It is easily identifiable by NVDA right now, at least in Visual Studio 2017 and 2019.

Great!

Have you considered splitting this text into at least two parts (two elements)? Right now, even if we can identify the element/object from UIA tree, it is very verbose.

If all screen readers correctly read name and help text, I'll be happy do it. Unfortunately, I have no means of detecting NVDA to provide different experience

Have you considered employing controller for event? This will then allow NVDA and Narrator to treat IntelliSense list as an auto-suggest control. This will work properly if controller for property does return IntelliSense list, and the one we wish to use is selected automatically and actually shows up as selected to UIA clients.

Sure, let me know where I can learn more about controllers and how I can achieve this. Currently,

• We're raising AutomationEvents.MenuOpened event
• We're setting contents of the live text block

If controller for event doesn't work, how about asking Windows Shell team to let you borrow the logic used for hardware keyboard input suggestions? This may involve redesigning the accessibility representation of IntelliSense suggestions as a list control, thereby allowing arrow keys to be used to navigate between suggestions.

That won't be possible. The Intellisense UI and its interactions may not be changed.

[josephsl]

Hi,

Correction: controller for, not controllers.

Although the following document isn't really applicable here, it explains how certain UIA events work behind the scenes:

https://github.com/josephsl/wintenapps/wiki/w10addoninternals

The NVDA source code itself does provide examples of how the screen reader will interpret some (if not all) UIA controller for events.

As for help text: I wouldn't recommend putting help text as a label for a control that should be announced. Although some may justify by saying that it is essential to give folks commands they can use, when it comes to productivity and efficiency, getting the job done by just announcing the suggestion would suffice.

As for detecting NVDA, you can use system SR flag (GetSystemMetrics function) to detect if a screen reader is running.

As for menu open/close event: according to NVDA source code, NVDA will treat UIA menu open event as gain focus event, meaning that NVDA will announce whatever item receives (or is being fooled into receiving) system focus.

Thanks.

[AmadeusW]

How do we prevent NVDA from reading out the entire line of code when user is scrolling through the intellisense list?

[AmadeusW]

Another issue: NVDA does not read tooltips. When tooltip is opened, AccEvents reports this, and we expect screen reader to read the value of the Name property

UIA:AutomationEvent [ToolTipOpened] Sender: ControlType:UIA_ToolTipControlTypeId (0xC366), Name:"class Microsoft.CodeAnalysis.CSharp.Syntax.AccessorListSyntax", HelpText:"", ItemStatus:""

Edit: Tooltips are set to on

[josephsl]

Hi, possibly because this is disabled by default in NVDA – one needs to enable this via NVDA Settings/Object presentation/Report tooltips. Thanks.

[josephsl]

Hi,

Preventing reading of current line under cursor: a bit tricky. The long-term solution is changing how IntelliSense results are presented to screen readers by exposing suggestions as list items, thereby allowing NVDA and other screen readers to take care of it through logic that ships with them. For short-term, perhaps live region change or name change could suffice, but this again could become an issue later.

In an earlier post it was stated that UI for this particular feature cannot be changed (if I understood correctly). While I and other developers and users understand this sentiment, when we consider UI presentation and accessibility, that decision may come back to haunt us later. Part of what makes apps accessible (something I can testify as a Windows Insider and have been advocating for a while) is a user interface and user experience design that shows that developers do care, even if it means trying to think about alternatives that improves not only the look and feel, but accessibility as well.

Here's what I think may (and should) need to happen in order for all parties to be on the same page:

1. Please talk to Narrator team (Jeff Bishop, for instance) so you can ask questions about how UIA clients actually work behind the scenes and get an idea as to how Narrator did or could resolve this issue from their side.
2. If you are willing, take a look at NVDA source code (specifically, UIA files) and see how NVDA takes care of various UIA events.
3. Please do talk to other product teams at Microsoft and exchange a dialogue regarding how to improve accessibility of IntelliSense and others.
4. If you are really willing to do so, please engage the Visual Studio team and related teams in a serious discussion about how UI and UX choices exposes deeper attitudes and vice versa, especially when it comes to accessibility.

In regards to the fourth suggestion, I'm not suggesting this lightly. I do applaud Microsoft for making sure products are accessible. But without a really serious discussion about deeper attitudes, current efforts may only remain a window shade. I do understand that what I said may come across as a blunt criticism or a harsh word, but I think this is a golden opportunity for us to sit down and think about attitudes, because that's one variable that will decide success of future Visual Studio releases and related technologies from accessibility point of view.

Thanks.

[DanteGagne]

Hey folks, I'm Dante Gagne and I'm the accessibility driver for Visual Studio. My responsibility is coordinating the various efforts around Visual Studio and the sister products to be compatible with today's ATs.

Joseph, I completely agree with your assessment as far as engaging with the Visual Studio team, and our overarching goal here is for a solid experience with all ATs. The Intellisense experience is one that's been refined over quite a few releases and the very non-standard experience is one that we've gotten feedback, from sighted and blind developers as well, that it does what folks want it to do. Unfortunately, it is a very non-standard experience in terms of how the focus model works. The goal around the particular control is actually to reduce needed keystrokes and in many customer studies, it's very fast and efficient.

We currently have a great experience with both Narrator and JAWS and we've gotten feedback from the blind community that it works very well. We're having a few issues with NVDA, and @AmadeusW is just looking to find a solution. My goal here is to make sure that users get an optimal experience, regardless of the screen reader that they use.

[francipvb]

We currently have a great experience with both Narrator and JAWS and we've gotten feedback from the blind community that it works very well. We're having a few issues with NVDA, and @AmadeusW is just looking to find a solution. My goal here is to make sure that users get an optimal experience, regardless of the screen reader that they use.

Right, I've tested Visual studio with JAWS 2019 (demonstration mode) and it works very well.

I think that the right approach would be to see what JAWS does right related to UIA and accomodate NVDA's code to work the same, but I prefer to let this decision to NVDA project members. It would propagate a better functionality to UIA support in general.

About IntelliSense tooltips and screen readers, I saw that JAWS says information about parameter information and such things while writing code. I will test a bit tonight.

Cheers,

[josephsl]

Hi,

I'm thinking more towards using Narrator as an example in Windows 10.

Update: I'm working on it at the moment.

Technical: do not rely solely on automation ID - class name is more reliable. Also, because too many name change events are fired, use something more useful such as UIA item status event (NVDA tracks this event from 2019.1 onwards). I'm performing some event handling tests to determine which event is more reliable and how to detect various item status differences.

As for silencing text editor content, at least speech.cancelSpeech function in NVDA might work, although I'm sure there is a much better workaround.

Thanks.

[josephsl]

Hi,

For anyone planning to work on resolving this:

1. Do not use name change event unless we get really compelling justifications regarding its superiority over other events.
2. Try using UIA item status event. Note that you need to be careful about this, as it announces highlighted IntelliSense items twice; item status text differences are seen, which is the way to detect what element to announce.
3. You may need to work with event queueing and speech canceling functions to prevent NVDA from speaking code editor content while IntelliSense is open.

For folks curious as to how I got it working:

1. Prepare a version of NVDA (installed or portable, doesn't matter).
2. Install Windows 10 App Essentials add-on.
3. After installing the add-on, restart NVDA with debug logging enabled (NVDA+Q, then select the last item).
4. Use IntelliSense.
5. Open NVDA log viewer (NVDA+F1) and inspect the log output, paying attention to three things: your commands, what NVDA said, and debug/event tracking output from Windows 10 App Essentials add-on (w10: ...).

With NVDA restarted with debug logging, Windows 10 App Essentials add-on will record the following for UIA events it knows how to track:

• The type of UIA object
• Element name
• Event being handled
• App module, including process ID, executable name and address where the app module code has been loaded
• UIA automation ID
• UIA class name
• Additional info for certain events (item status string for item status event, for instance)

Thanks.

[francipvb]

Hello,

@josephsl wrote:

Hi,

For anyone planning to work on resolving this:

1. Do not use name change event unless we get really compelling justifications regarding its superiority over other events.

2. Try using UIA item status event. Note that you need to be careful about this, as it announces highlighted IntelliSense items twice; item status text differences are seen, which is the way to detect what element to announce.

3. You may need to work with event queueing and speech canceling functions to prevent NVDA from speaking code editor content while IntelliSense is open.

For folks curious as to how I got it working:

1. Prepare a version of NVDA (installed or portable, doesn't matter).

2. Install Windows 10 App Essentials add-on.

3. After installing the add-on, restart NVDA with debug logging enabled (NVDA+Q, then select the last item).

4. Use IntelliSense.

5. Open NVDA log viewer (NVDA+F1) and inspect the log output, paying attention to three things: your commands, what NVDA said, and debug/event tracking output from Windows 10 App Essentials add-on (w10: ...).

With NVDA restarted with debug logging, Windows 10 App Essentials add-on will record the following for UIA events it knows how to track:

* The type of UIA object

* Element name

* Event being handled

* App module, including process ID, executable name and address where the app module code has been loaded

* UIA automation ID

* UIA class name

* Additional info for certain events (item status string for item status event, for instance)

Thanks.

I had problems trying to code a stable solution with this approach, because when you open the Intellisense popup an help message is spoken. The "ItemStatus" event is not fired consistently across implementations. I decided that the best approach is to stick with the text block next to the items list, it fires a "liveRegionChange" event when you select an item and when it appears.

Cheers,

[adincebic]

Hello everyone, do we have any news regarding this issue?

[Adriani90]

@Luke-Robinett I think this will be solved in the future, I am quite sure. But as of now the priority for this might be low. This could change in time. So please keep this issue updated when a new version of Intellisense is published.

cc: @taymun26

[dyaminigo]

I support this topic and I also really want the IntelliSense problem to be fixed as soon as possible. The inability to program normally using IntelliSense really upsets me and at some points slows down development.

[LeonarddeR]

I also use Visual Studio daily and suffer from this issue, though it's not a big problem for me as I use braille every day. However without braille and with long lines, I can see that it's a real pain.

@AmadeusW and @DanteGagne, it's good to see that you are motivated to work on this somehow.

I believe @francipvb put some effort in making intellicense work using UIA menu and item status events, but this was very slow, probably because NVDA"s event handling. I'm pretty sure #11214 can improve this.

Another approach could be improving the way live regions work, as currently, speech priority is not considered for the different levels of live regions.

[manish10]

Is anyone still looking into this? @DanteGagne do you know if any upcoming work will resolve this?

[akash07k]

Same here, this issue is quite frustrating as well as downgrades the productivity. @feerrenrut @michaelDCurran Can you please look into this?

[beqabeqa473]

100% agree with people above. after using vs about 30-40 minutes it becomes very tiring and it rrally slows down development process

On 9/6/20, Akash Kakkar notifications@github.com wrote:

Same here, this issue is quite frustrating as well downgrades the productivity. @feerrenrut @michaelDCurran Can you please look into this?

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/8336#issuecomment-687714780

-- with best regards beqa

[francipvb]

Hello folks,

I was working on it, but I can't find a good solution to this issue. The fact is that I'm not sure where is the problem, likely in the NVDA UIA implementation.

The internal issue is that after some time, the UIA events processing become more and more slow, so there is no viable solution.

Visual Studio has so much information to render to NVDA, like the floating documentation. I was experimenting with these things but because I stopped using Visual Studio, I became less interested in this issue.

Sorry about this.

-- Cuando tus fuerzas terminan, las de mi Dios comienzan.

[LeonarddeR]

I am using Visual Studio every day and, since I implemented selective registration for UIA events a while back, things really started improving for me. You can find this option in recent alpha builds, under the advances section in settings.

[josephsl]

Hello everyone,

For people finding out about this for the first time: to summarize, the issue is that IntelliSense items are very verbose, as the line under the caret will be announced alongside these items.

Based on latest tests, it turns out it is a combination of caret movement detection and events. The strategy I'm eploying (to at least solve this for now) is:

1. Define an overlay class for the live region responsible for announcing IntelliSense area. This is required so that the overlay class can tell NVDA to not handle live region change event.
2. Define UIA element selected event handler either inside the app module class or as part of a dedicated IntelliSense menu item overlay class. The purpose of this event is to inform NVDA that a UIA list item was selected so it can announce these items whenever you press up or down arrow. In order to avoid verbosity, as part of element selected event handler code, speech.cancelSpeech function must be called.

Try implementing the following algorithm inside Visual Studio app module:

def event_UIA_elementSelected(self, obj, nextHandler):

1. If not imported at the top of the app module (devenv) file, import speech, api, and queue handler modules (queue handler is spelled "queueHandler").
2. Set navigator object to the just selected intelliSense item.
3. Cancel speech.
4. Call obj.reportFocus method to have speech announce the just defined navigator object. It may appear to be verbose because both the lavel and the description will be announced.
5. In consideration for braille users, you must import and call braille.handler.message(braille.getPropertiesBraille(name=obj.name, role=obj.role, positionInfo=obj.positionInfo)).

Hint: does the algorithm look familiar? This is because it was copied directly from the code responsible for announcing emoji panel items in Windows 10 (I am the author of that code fragment as well.

Note that there might be times when live regions might be useful, or older VS releases do not implement UIA element selected event for IntelliSense (after all, Visual Studio (at least code editor portion) is a Windows Presentation Foundation (WPF) universe).

I myself do not use the IDE portion of Visual Studio - I just use it to compile NVDA from source. Therefore, I think it would make more sense for an actual VS user to submit a pull request that will (finally) close this issue.

Thanks.

[francipvb]

Hello,

El 9/9/2020 a las 14:16, Leonard de Ruijter escribió:

I am using Visual Studio every day and, since I implemented selective registration for UIA events a while back, things really started improving for me. You can find this option in recent alpha builds, under the advances section in settings.

I've tested my solutions with this experimental option enabled without success, unfortunately. I think that the issue is in another place.

Cheers,

-- Cuando tus fuerzas terminan, las de mi Dios comienzan.

[francipvb]

Hello,

I've tried your proposal as part of my attempts to solve this issue. The problem is that the live region changes not only when you select the list item, but various times later, even without user action. Another issue is that as the time passes, the item takes more and more time to respond...

Cheers,

-- Cuando tus fuerzas terminan, las de mi Dios comienzan.

[francipvb]

Hello again,

I have related code with your solution. I missread your comment. I will give it atry later and post some code if I have time.

Cheers,

-- Cuando tus fuerzas terminan, las de mi Dios comienzan.

[francipvb]

Hello,

If you want to develop with Javascript, I think that VSCode is a better solution these days, as long we have a good solution for the Visual Studio users.

Note that VScode has support for C#, but it is not good as the Visual Studio support.

Cheers,

-- Cuando tus fuerzas terminan, las de mi Dios comienzan.

[feerrenrut]

NV Access developer here.

I can understand that this is causes frustration, but I'd like to remind everyone to consider their tone to help us to encourage a positive community based around collaboration. There are many ways to provide helpful contributions to an issue in order to encourage it's progression, if you aren't sure please ask what you can do to help.

NV Access (the small non-profit that shepherds the NVDA project) aims to provide the most benefit for the majority of users, attempts to further accessible standards and encourage accessible application development. Sometimes this means putting pressure on application developers to fix issues they have created on their side rather than just working around them. It also means that we have to prioritize what we work on. NVDA users who work with Visual Studio are likely to be some of the most well positioned to address issues in NVDA. That said, it is never an easy decision to prioritize one thing over another.

At this point, I can only speculate, but the attempts to address this issue by several note-worthy NVDA contributors indicates the complexity of this issue. The fact that Narrator and Jaws are able to overcome this tells us that it is not impossible, but even then does not automatically make it something which should be fixed from NVDA's side rather than Microsoft's, but the root cause at this point needs further investigation. As you noted earlier, there have been other higher priority issues which have more severely impacted a greater number of users. As a small organization we only have two developers on staff (we are currently in the process of hiring another staff member), so we do need to prioritize what we can work on as best we can.

What would be helpful at this point, please, would be if you could test with the latest alpha snapshot see "Enable selective registration for UI Automation events and property changes" in the user guide for details of the feature. That contains the fix mentioned by @leonaddr from PR #11214. It would be useful to know if that improves the responsiveness of Visual Studio for you.

[Luke-Robinett]

Hi. I just downloaded and installed the latest alpha build and experienced the same issue. I tried enabling the UI automation setting mentioned above but also didn’t notice any change in the behavior. I’ve got the alpha installed as a portable copy as not to overwrite my normal NVDA installation. Please let me know if you’d like me to try any other steps or settings. Thanks.

[feerrenrut]

Thanks for testing @Luke-Robinett. As requested, I have removed your name from the comment.

[akash07k]

I agree with your point that VS code is a better choice for javascript development, however, VS Code lags very badly with NVDA regarding that the issue is opened.

Hello, If you want to develop with Javascript, I think that VSCode is a better solution these days, as long we have a good solution for the Visual Studio users. Note that VScode has support for C#, but it is not good as the Visual Studio support. Cheers, … -- Cuando tus fuerzas terminan, las de mi Dios comienzan.

[francipvb]

Hello,

I have to check it. However, I didn't saw major issues with VSCode and NVDA, and I use it every day for my work. Unfortunately I'm using mostly with Dart/Flutter.

Cheers,

-- Cuando tus fuerzas terminan, las de mi Dios comienzan.

[LeonarddeR]

Update: my earlier assumptions in this message were wrong, feel free to ignore it if you read it somehow (e.g. by e-mail). Message is now up to date.

As I am also a daily visual studio user, I have looked into this issue again. I noticed that the live setting of the live text block is set to assertive. Therefore, NVDA behaves wrong here, it speaks the currently selected line (since the focus is on the text area) and it queues the speech of the region after that. It should speak the live region first, like Narrator does.

[LeonarddeR]

Here is a try build that respects aria live politeness and therefore should speak updates instantly.

[manish10]

I tested this snapshot build with visual studio 2019 latest and c# and it is better than before. It speaks the live region first and then speaks the line of code. I think that is also the discussion you had on the other bug you linked to. This is much better than before. It will be great if we can cancel the speech from the current line also but I can work with this for now.

[Luke-Robinett]

@manish10 Great! I will grab the latest alpha and give it a shot. Thank you so much.

[Luke-Robinett]

@alex19EP I saw you gave one of my above comments a thumbs down but I am unclear why, as it was a harmless/reconciliatory comment to another user. Was this done in error? I plan to remove the comment anyway but wanted to better understand why I recieved the negative feedback. Thanks.

[Luke-Robinett]

Regarding the latest alpha build, could the fact that I installed it as a portable copy instead of full install impact anything? I didn't experience any improvement in the IntelliSense issue while testing using it, but then it occurred to me maybe it's because it was the portable version. Maybe that doesn't make a difference but thought I'd ask, for the sake of thoroughness. Thanks again, everyone.

[josephsl]

Hi, you can try with selective UIA event registration (NVDA menu/Preferences/Settings/Advanced, first check the “I understand” checkbox, select “enable selective UIA event registration”, click OK, then must restart) and see if that makes a difference. Thanks.