Apparently Microsoft just made a security decision to block any application, even a trusted screen reader, from injecting its code into any WinRT application.
This includes Windows core components like the start menu, settings app and Microsoft Edge. This also means windows store apps as well.

This greatly reduces accessibility in all these essential apps and in particular edit boxes. We are pretty much writing silently and there is no sound for when we misspelled something or when a suggestion comes up.
Microsoft is moving more and more to having all their apps and components be packaged like this, so I am scared that soon screen readers will be left with only minimal access, effectively barring blind users from competently using Windows.

There are solutions to this problem and I know NV Access has reached out to Windows about this problem, but Windows has not yet responded with a suitable alternative.

I'm not a screen reader developer, but maybe all Windows apps could be built on a back-end that exposes information screen readers need and maybe even requires proper labeling like what happens on Mac computers.
Another option is Windows have a list of screen readers and hand out access keys so they can grab the information they need. This could either happen on Windows' end or the user can choose what applications have full access to all their apps.

Regardless, this is a huge problem and I am appalled that such a major accessibility bug made it to the stable version of Windows. This really shows just how much Microsoft cares about and listens to their blind users and developers.
Again I ask Microsoft to have an official beta testing group of blind people who have a very high influence on Windows development and who can find bugs before they get released in to even the insider program. Microsoft has slowly demolished every feature that blind users love and has been actually decreasing the accessibility of windows.
Please reverse this trend!

I recently purchased an Xbox console. Here are my thoughts on the experiences so far and I think an underlying theme of where accessibility breaks and needs to improve. I am really passionate about making this a good console for users, so opening dialog up about this is critical. That's why I was super excited when I purchased my console a few weeks ago, a moment where I was confident that at least I'm getting some out-of-box accessibility solutions and a company dedicated to their mission.

First, the biggest issue with Narrator, as it stands, is this controller-keyboard compromise I mention in the subject line. When I first opened the console and set it up, I used windows + enter on the keyboard to start up Narrator. I wish I would have tried the controller, but alas, I didn't. Still, I switched quickly to using it because I remembered how the navigation works with each stick / scrolling with the trigger buttons, so I thought it would work easier.
Boy was I wrong. The problem is that the navigation done by this d-pad on the controller is different than your standard tab and shift-tab action. I believe there were dialogs, like the wi-fi selection, where I could not use the controller but had to rely on the keyboard. In any web content, such as when you're creating a live gamertag for the first time and are asked questions, navigation with the stick is not possible. I had to switch to the keyboard because I also wanted to type quicker, and noticed this.
Then we get to the main Xbox interface. When you tab and shift-tab in there, Narrator will sputter and just can't handle itself. Alt+tabbing works, and I know there are shortcuts on the keyboard for multitasking. I have used these before and of course Narrator includes a set of its own commands for things like speech rate changing. Again, changing speech rate is not possible from the controller as of now.
Any kind of text content, such as static text on a label in a dialog, cannot be read or explored with the controller alone.
Why should those who are users of the screen reader rely so much on this disjointed interaction model between keyboard and controller? Should we be required to use a keyboard just because a screen reader is in need of more commands which would be harder to map to a 5-10 function input device? (Note: I didn't count this, but logically thinking...) For which commands should keyboard interaction be retained? For example, I would not expect to change verbosity levels on the controller or have special table reading commands. Putting performance issues aside with Narrator (and why some UWP apps like Pandora crash after Narrator is running but not before,) this is a huge issue which, in my opinion, plagues accessibility forward.
The closed-nature of the Xbox insider program means getting access to this seems difficult at the moment, but I'd love dialog from anyone at Microsoft, and especially the community of those using this product, on what their thoughts are. I'm thrilled that Microsoft has a chance to be innovative in this space, being essentially the first console to provide a full-level screen reader experience. I am 100% in no doubt that the engineers and teams there are aware of this problem to some degree, so perhaps having more insight on the experience from a user could bring greater clarity (and urgency) to that situation. :)

With respect-
Tomi

A reputable company Microsoft, I apologize in advance for not being an exact translation (if he is), so I really do not know much English. I have just a few moments ago I saw your creation HoloLens, and I was deeply impressed by this device. And I would like to tell you about a text concept of absolute immersion in virtual reality devices.
It is a capsule full immersion, in which a person falls into a trance or dream, using neural helmet that reads brain signals and converts to a digital signal, creating a virtual reality of total immersion, in which a man can fully move, though his body is asleep. Yes, I know that such a device is on the verge of science fiction, but judge for yourself that just ten years ago, over those who thought about glasses virtual reality, were considered mad and eccentric. But augmented reality as HoloLens already developed, presenting a digital interface that syncs with elements of reality. So, such a capsule not only gives access to the full immersion, but it does so the same will allow people with disabilities to feel like full control over the capsule. But apart from this reading technology and processing signals of neurons allow sozdovat implants of the new generation! Such prostheses are head and shoulders above its predecessor in all respects.
I'm already used to think a lot of technology, starting with the usual microSD adapter on the Universal Serial Bus and wireless headphones, and ending with virtual and augmented reality. Then I thought that the imagination of a little boy no one will Iteresno, and I was afraid of being ridiculed. And all of what I once fantasized already created proxy. And HoloLens becomes the last straw bowl because I missed a chance to leave a mark. And being a dreamer and a theorist, I have neither the knowledge nor the experience in this field. I am writing this letter in the hope that my ideas once they see the light.

The current command line works pretty good, but there are two major problems that showed up particularly in windows 10:
1. You need to use the review cursor to read the command line. This is OK, but not novice friendly and has always been the case.
2. When one has "speak typed characters on" or "speak typed words on" I will hear new output spelled to me rather than read normally. This is beyond aggravating!
Next, the new Bash client acts like the command line, but when using things like SSH, Nano or Vim, it acts a little strangely.
For example:
- In Nano everything is great, except when trying to read documents you open. The documents are blank. New documents are fine, but old documents are blank.
- Vim should have an option for verbosity as telling me the number of characters I am on is a little crazy. It also doesn't tell me what line I'm on when in review mode and reading the lines. Using hjkl to move around the text doesn't work either.
- SSH is what I would really love to see made amazing. It is just about there, there are just a few things that don't work very well (Note these problems are just in SSH, no where else):
1. When typing with key echo on in ssh, it has a lag. I will hear the letter half a second after I type the letter.
2. Erasing gives me no audible feedback what so ever. It is just silent when I hit backspace. I should hear the name of the character being erased.
3. Arrowing through the line gives me no audible feedback either. It should read the letters. When up arrowing to read the buffer of past typed lines I hear nothing either. I should hear the lines I typed before read to me.
4. Typing passwords gives me no feedback. I would like to hear "star" or something like that. I really like what the logon screen does now.

The default high-contrast themes do not make use of the option to set a background color for buttons. Instead, they rely on the fact that default button styling includes a border, and set that border to the button text color. Buttons are thereby visually distinguished as text surrounded by a border. Some of the default high-contrast themes also use a different text color for buttons, but not all.

This creates a problem when these styles are applied to websites in MS Edge. Many modern websites do not use border styles on buttons, instead relying on the background color, rounded corners, and graphical effects (e.g., shadows or gradients) to visually distinguish buttons. When the standard high-contrast styles are applied, buttons without borders lose any visual distinction relative to the rest of the text.

One option would be to force a border on all buttons when high-contrast mode is in use. But this would likely throw off the layout of many websites, since adding a border changes the size of elements. Adding a distinctive background color causes fewer side effects.