Tom, This is really interesting and it seems odd this has not surfaced before from screen reader developers. I have often run NVDA when Window-Eyes went quiet and then closed NVDA when everything seemed to resolved itself as you described. Sometimes I would note unusual behavior and assumed it was due to system instability. Of course, the system could have been unstable, but I wonder now to what degree it might have been the screen reader flag being set to false.
In addition, I am very curious about Narrator not using this flag. It would seem Microsoft is either feeling that they have other methods to get the information they need or they want to see how it reacts to software with the flag not set. Thanks for sharing this information. Best regards, Steve Jacobson -----Original Message----- From: Talk [mailto:[email protected]] On Behalf Of Tom Kingston via Talk Sent: Tuesday, November 07, 2017 1:54 PM To: Window-Eyes Discussion List <[email protected]> Cc: Tom Kingston <[email protected]> Subject: A little tech tip on Windows and screen readers. For years Windows has had a screen reader flag that our screen readers set to true when we load them and false when we close them. Most programs don't pay any attention to this, but there are programs that do. And Windows itself actually does a little work to feed our screen readers some information that would otherwise be inaccessible when this flag is true. While writing a program I needed to look up the Windows SystemParametersInfo function for something unrelated. It is a doorway to numerous system parameters. In doing so I was reminded that it's also where a pile of accessibility parameters are accessed as well, e.g. screen reader, high contrast, keyboard access preference, no animations, visual effects, etc. All of these have get and set functions. A common scenario probably most of us have experienced is that our screen reader goes silent. So we fire up another one to see what's going on. For example, Window-Eyes will stop talking occasionally with IE error messages. But for some reason, usually, as soon as I fire up NVDA, or close the error message window with NVDA, Window-Eyes comes back to life. The point is that I end up with two screen readers running simultaneously. I always assumed this would mess with the screen reader flag status. And stumbling upon this offered me a golden opportunity to get away from my real work. So I wrote a little program to check the screen reader and keyboard preference flags. the latter is to indicate to developers that you want keyboard access rather than a mouse driven interface. I doubt anyone uses or pays any attention to this because if they did a purely mouse driven graphical interface would be replaced by a keyboard driven interface with standard controls. At least that would be the best case scenario. Our screen readers don't set it to true anyway because the screen reader flag is saying the same thing. It's another case of the elements existing and not being used. Case in point, W3C web standards. But I digress. The driving force was that I've known about this for years and suspected that loading another screen reader atop an existing one and then unloading either would leave the screen reader flag false. My program confirmed my suspicion. I may have mentioned this before because I was told about this years ago. But I wanted a concrete answer. And I was curious as to whether it had been improved. Although I have been operating on my assumption ever since hearing about it initially. I ran my program with Window-Eyes running and then after unloading it. I then did the same with NVDA. I haven't installed JAWS on my new system yet, but I assume it will do the same. When one is loaded the screen reader flag is true and when it's not it's false. And if I load either while the other is running and then unload one of them I still have a screen reader running but the screen reader flag is false. The reason I wanted to know this for sure is that I thought if common sense had prevailed there would have been a simple screen reader counter. That way the true count could stack up and screen reader would not be false until the counter was zero, which is always false in programming logic. Evidently common sense didn't prevail on this one. So now you know. I recommend reloading your screen reader if you have to load and then unload another to get out of a jam. And here's the bonus prize! Narrator does not set the flag true. So you don't have to worry about it if you load Narrator atop another screen reader. Why this is is beyond comprehension. But Microsoft states it clearly on their developers network and my program confirmed it. I suppose they incorporated a seperate internal flag for Narrator. Who knows. Regards, Tom _______________________________________________ Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Ai Squared. For membership options, visit http://lists.window-eyes.com/options.cgi/talk-window-eyes.com/steve.jacobson %40visi.com. For subscription options, visit http://lists.window-eyes.com/listinfo.cgi/talk-window-eyes.com List archives can be found at http://lists.window-eyes.com/private.cgi/talk-window-eyes.com _______________________________________________ Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Ai Squared. For membership options, visit http://lists.window-eyes.com/options.cgi/talk-window-eyes.com/archive%40mail-archive.com. For subscription options, visit http://lists.window-eyes.com/listinfo.cgi/talk-window-eyes.com List archives can be found at http://lists.window-eyes.com/private.cgi/talk-window-eyes.com
