Visual studio sort of works, but it depends which version.  Every version has its own unique special big problems, and I sort-of-jokingly call it the choose your hell adventure game.  The problem is that for stuff beyond the basics, Visual Studio is it for windows-there are huge swathes of the Windows API that aren't on MinGW, and VS is the only IDE that talks to the MS compilers right.
Eclipse is more accessible, assuming you can get it set up in the first place.  But doing that isn't so easy for C++, requiring as it does a working MinGW or Cygwin toolchaijn and a bunch of configuration.
Now, I'm going to be "helpful", but you're going to disagree.  You won't in 6 months or so, but you probably will for now.  I know of few if any blind programmers who don't follow this path in the end and I know of few if any just-starting blind programmers that like this answer.  Nevertheless, it's the only one I and everyone I know have found barring a great deal of experience as a sighted developer before going blind:
Use the command prompt.  All your accessibility issues disappear, you get next to nothing from the IDE as a blind person, and literally any compiler works.  You'll also be in a quite good position to program on Linux down the road, administer a webserver, or to go into a variety of other different places.  It works with most programming languages, all version control systems I am aware of, and there are even some languages (like Python) where lots of sighted people do it, too.  Using cin and cout is how it's done, and because your IDE isn't redirecting to inaccessible text controls, you get them read automatically.  I know the command prompt can seem frightening, but barring some sort of legislative change or a suddenly philanthropic company caring and spending hundreds of thousands of dollars, you're going to spend more time in the end fighting your IDE than just learning the command prompt.
If you have Visual Studio, you can get at it by looking up how to launch the developer command prompt; cl myfile.cpp compiles, myfile runs it.  Literally everything reads with no further hoops.  Specific directions depend on the version, but once you figure it out you can make a desktop shortcut.  If you don't have Visual Studio, you want it because it's basically the only good Windows compiler.
What are you trying to do in C++, anyway?  We may need to go into project management and build systems for anything larger than very very small.  I'm not sure why C++ is coming up again-the "Should I use C++ for audiogames?" question has been hammered into the ground and buried forever, or I'd have thought anyway.  If you're dead set on it, go look at CMake, and then be very very afraid.  Or fight your IDE because your IDE does the same things, only with a ton of accessibility "adventures".  If you are dead set on C++ and nothing will sway you, then good luck for you will need it.  But seriously-with C++, figuring out how to deal with inaccessible IDEs is only the beginning of the exquisite horror.  I say this as an experienced programmer with thousands of lines of C++ code.  The best thing you can do after figuring this problem out is to stop asking questions here and get on Stack Overflow-the answers to most of the C++-specific problems are well beyond the scope of what most people here do.

That puts you in a minority.  A very small one.  Every other time I've said this to a new blind programmer, the reactions have been interesting.

A few things.

When your setting the various properties of controls, I'm pretty sure they look different depending on the property you set. If a control's enabled property is set to false, it's going to look greyed out or not even be there at all. Read only keeps the text control there, you just can't input anything. Similarly if you add a textbox occupying the same pixel coordinates as a label, you could run into potential problems. Keep in mind that there are transparency settings for controls etc, people are going to notice if you can tab to a label where you usually can't, the exception being link labels.

With visual studio, code is relatively accessible, despite some annoying focus changes and sometimes text not being read properly. If you are debugging, it's not accessible in the least. Some of the property dialogs act weirdly to, sometimes the focus for reading properties of controls screws up so the properties don't show up when you select the name.

No. This is wrong.
First, web sites are in fact easy.  That's why I'm so excited about Aria: in the case of web sites, it can be as easy as adding barely anything to the HTML.  In another couple years, once all the bugs are worked out, we'll be able to have desktop-like apps in the browser, and everyone will be able to play with accessibility.
But desktops aren't this way.  That alternative text on the image?  It involves implementing a COM interface and responding to a custom Windows message.  The total number of lines of code for adding support is somewhere around 500, assuming you even can.  Most GUI frameworks are at a very high level and you can't get in to where you need to be to do this.  If you are lucky, your framework already provides the support-I am aware of a grand total of 0 that do so but Winforms and WPF *might*.  Other things that are problematic depending on your GUI framework: changing a control's type as the screen reader sees it, adding accessibility information to a custom control, telling the screen reader that label a goes with control b, and I haven't even talked about the nightmare of making table controls accessible-there is a reason that I export to CSV and use Excel when I need such.
On the internet, your web browser translates HTML into the DOM, exposes the DOM, and hides all of this.  If you gave me an IDE that was fully in my web browser, I would agree with your statement-getting it to be accessible would be pretty easy, comparatively.  But doing it for a desktop app requires a ton of specialized knowledge.
But that's not even the worst news.  I am not aware of an IDE that doesn't use a custom framework or at least a custom control for something useful.  Microsoft is not using WPF or Winforms, they're using an internal toolkit that we don't have access to.  Older ones have less problems because they used to use more standard controls.  Netbeans and the stuff from IntelliJ are using Swing, but in such a way that you can't use them--not to mention the accessibility issues of Swing in the first place, and the fact that enabling it actually opens a huge security hole in your system (larger than normal for a screen reader).  Others use QT (finally starting to maybe get better, but with huge bugs yet) and GTK (don't hold your breath).  Even some of the built-in WPF and Winforms controls are inaccessible to one extent or another, though those tend to at least be passable.  The next best GUI toolkit for us, WX, isn't fully accessible either: all the advanced controls like property lists and tables need to be exposed, probably with IA2.
But there's one final hidden cost, too.  You have to hire someone with very specialized knowledge.  This isn't a $50000 job, this is a minimum $100000 job.  And you have to keep them hired or it just slips back to where it was over time and you might as well not have bothered.  But it's probably not one person, it's probably a team, so yes. It's expensive.  The only reason Eclipse is even accessible is that IBM paid for it: they wrote a custom GUI framework for it and had a team who put in the components needed, and yes, it was a huge effort.  The workarounds being suggested here change the visual experience drastically and are screen reader and screen reader version specific; they work for little blindie apps, but not for Microsoft who can't sacrifice sighted user experience for blind user experience.  Not to mention that your afternoon of playing isn't going to give you the years of experience needed to do this right the first time, and any company concerned about it also needs to be worried about 10 other disabilities-you're also going to have to give this team color changes, font changes, stuff related to dyslexia and all sorts of fun.
It's simply not going to happen, and I'm sorry that your optimism about it will be crushed in the near future.  I am certain it will. I'd bet just  about anything.  We're at the point of having to make laws in order to get companies to even care.  This is not a happy field, and there is a reason I have decided that it is not my long-term career goal: your accessibility team is often told to do the bare minimum so that if a lawsuit comes along they can say they technically met the guidelines.
And more people tab than you think-it is faster than a mouse if you know what you're doing or if you're trying to enter data in 50 consecutive text fields.
If you don't believe me, go try to make some WX controls accessible.  Then you will understand the scope of the problem you're brushing aside with "people don't understand us".

Yes, I've done crazy things too.  But by the time I'm doing something crazy, the app is not accessible.  Being able to use an app doesn't make it accessible, not by any definition you'd want to make meaningful.  Yes, you have to.  But if you promote that, the entire accessibility world becomes workarounds, and we don't want that.
This is meaningless, however: the big companies aren't going to use your little hack because they are selling a commercial product.  Anything that changes the experience for someone who isn't blind is questionable, and the justification to get it into the product will probably be involving at least 10 people.  You can't fix it for one release either; that's not good enough.  I need IDE x for my job, and when we upgrade, what?  Do I get fired?  Saddled with a sighted assistant for all of every day?  In the end, the command prompt is easier for this particular discussion--it requires almost 0 workarounds, especially for the command prompt friendly languages.
But in general, for Windows and Linux, there's basically no resources that I can throw you at for desktop accessibility.  Mac is a bit better in this regard, but not tremendously so.  You could probably get small companies to do it, but not for this-maybe 10% of blind people are programmers of the caliber required to get a job, and companies don't seem to care about hobbyists that aren't buying the product.  Could you convince them of the wonderful world of blind customers?  No, not really.  The good news is that we have a number of new laws coming into play that will make companies have to care, especially if they want to sell to education, but it's not there yet.  And blind programmers will probably always be shafted in this regard for the simple reason that there are not enough of us by any stretch of the imagination.
People don't realize how amazing the web is in this regard.  With just a little HTML knowledge, a copy of NVDA, and an afternoon with the internet, one person can often do it.  With desktop apps, it requires more--usually C++, always COM, almost always access to the window callback procedure (some GUI frameworks let you intercept this properly), a huge amount of boiler plate for even simple little things like labeling.  I can point at the necessary MSDN pages if there's interest, but it's certainly not for the faint of heart.

The laws I'm aware of are US only, but I believe they will affect non-US companies which wish to sell to the US.  I'm not 100% up on this issue, but we're finally getting more and better usability requirements--at the moment, the biggest issue is that there's a checklist and the checklist is all that matters, the end.  Look up 508 Refresh.  Also CVAA.  There's another one that's currently important, but I'm not remembering the name.
I'm not sure what you mean by root, not in a Windows context.  Since Linux accessibility is worse than Mac accessibility, I'm not bringing it into this discussion--they're not even able to get things like audio right, let alone have the huge driving force that Windows benefited from.  I'm specifically against unscalable solutions and, unfortunately, screen reader scripting is such no matter how you slice it.  You move the tremendous amount of resources needed to make apps accessible from the people writing those apps, pile them up in the corner, and dump them on one, usually small, company.  While I fully understand the reasoning and know that without it accessibility would probably have been stillborn, the Jaws philosophy of scripting everything is now coming back to bite us in a way.  People are used to solutions that involve hacking the graphics card and the app developers have this mentality of someone else's problem.  We suffer from a lack of tutorials, and it's just generally shoved into the corner.  The truth of the matter is that it really belongs to the GUI frameworks, and that if people like QT put a big push behind making it work we'd suddenly have hundreds and hundreds of apps that just started being fine.  I'll take the workarounds when I have to.  but I will never endorse them because it just hurts everyone in the long run.
As for Visual studio and Sodbeans, well, I tried Sodbeans once and didn't really get anything out of it at all.  Visual Studio tends to have this little trend of becoming less accessible, with a hard dip for VS 2012.  At the moment, the debuggers don't work with anything but jaws.  This falls under the hacky workarounds that hurt us.  I reported it and Microsoft doens't care.  Other funny little things: submenus don't show up as submenus and you have to recognize them because they're the only menu items that are "unchecked" according to the accessibility API, alt-tabbing out works inconsistently (I think this has to do with color scheme, but you can get stuck in a strange phantom menu bar), 2012 at least had multiple places where you could tab in but not back out, and that's when I gave up.  I'm 100% sure there is more.  Jaws works around some of this with display driver hooking, but it's still definitely unpleasant.  2008 and 2005 are much, much better and, if you (like many others who have not had to deal with invalid pointers or have never tried one) think debuggers aren't necessary, it's almost fine.  but not great, not fast, and definitely unpleasant.