Tom, That is a little geeky, but still interesting. Thanks for sharing.
-----Original Message----- From: Talk [mailto:[email protected]] On Behalf Of Tom Kingston via Talk Sent: Tuesday, November 07, 2017 12:54 PM To: Window-Eyes Discussion List Cc: Tom Kingston 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/robin.van.lant%40key.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 This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:[email protected] with 'No Promotional E-mails' in the SUBJECT line. _______________________________________________ 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
