RE: A little tech tip on Windows and screen readers.
Tom, This makes good sense to me, and to be clear, you know much more about this than I do. Thanks for sharing this information. Best regards, Steve Jacobson -Original Message- From: Talk [mailto:talk-bounces+steve.jacobson=visi@lists.window-eyes.com] On Behalf Of Tom Kingston via Talk Sent: Wednesday, November 08, 2017 10:33 AM To: Steve Jacobson via Talk Cc: Tom Kingston Subject: Re: A little tech tip on Windows and screen readers. Steve, I agree that the complicated route isn't the one to take. And I agree that programs would only check the flag on launch. But in the way I'm looking at this that's fine. If the flag gets set to false after shutting down a second screen reader and the first one is working fine I won't have to relaunch programs. And if I run the program to reset the flag after closing the second screen reader it will be true for any programs I launch thereafter. So the trick would be to run the program as soon as we shut down the second screen reader, which is what I would do because otherwise I'll forget. And after resetting the flag I can broadcast a system message that the flag was changed. So all those wild little party animal programs will be notified. Regards, Tom On 11/8/2017 10:37 AM, Steve Jacobson via Talk wrote: > Tom, > > Given my tendency to believe that the more complex something is, the more > likely it will cause problems, I think it might be useful to be able to > simply reset the screen reader flag upon demand as you suggest. While I > don't see any flaws in your logic, I would caution that there could be > applications that only check the screen reader flag when they start. In > other words, resetting the flag to true might not solve all problems. One > would assume that the operating system would know the flag was reset, and > that might resolve most of the problems that would arise, though. I have no > knowledge of how that flag is checked so this is all speculation which is > also dangerous. > > Thanks for this information. > > Best regards, > > Steve Jacobson > > -Original Message- > From: Talk > [mailto:talk-bounces+steve.jacobson=visi@lists.window-eyes.com] On > Behalf Of Tom Kingston via Talk > Sent: Wednesday, November 08, 2017 8:52 AM > To: Olusegun -- Victory Associates LTD, Inc. via Talk > > Cc: Tom Kingston > Subject: Re: A little tech tip on Windows and screen readers. > > Olusegun, > > John is right. The program I wrote was just to confirm the problem. But > I read your message a while ago and have been pondering it while > luxuriating in Peet's coffee. That's my latest low-tech discovery. > Highly recommended. (smile) > > WARNING! If you don't want to geek freak out close this message now! > Three ... two ... one ... lift off! > > Solving the screen reader flag problem programmatically is possible, but > not very practical. A program that would take care of it automatically > would need to be loaded at startup, wait a little while, and check to > see if the flag is true. Then it would know your screen reader is > running. (No assumptions is the golden rule in programming.) If so it > would then have to begin a process loop. Here's what that loop would > have to do. > 1. Enumerate all the running processes to see if a screen reader is > loaded. I might be able to query for Window-Eyes, NVDA, and JAWS > individually. > 2. Get the screen reader flag status and see if it's false. > 3. If both conditions are true then reset the flag to true. > 4. Put the program to sleep for whatever time is determined to be > reasonable for how often the check is performed so it doesn't bog down > the system but doesn't wait too long before resetting the flag. > 5. Iterate the loop and repeat the above steps. This is done > automatically but it is a process nonetheless. > > Checking the flag is a simple function, but building a construct with > all running processes isn't exactly a small task. It's more or less a > slimmed down shell of the Windows task manager without a UI. So I gave > this idea a thumbs down. > > Then a more practical approach came to mind. It would be a program you > could run to see if the screen reader flag is true and prompt you to > enable it if not. Yeah ... but, I thought, this really gets back to the > original solution of remembering to reload your screen reader because > you'd have to remember to run the program. But wait! I thought. It would > be beneficial because reloading our screen readers while some programs > are running requires us to close and reload the program due to the > preparations our screen reader does for that program when it loads. For > example, when I'm in my programmi
Re: A little tech tip on Windows and screen readers.
Steve, I agree that the complicated route isn't the one to take. And I agree that programs would only check the flag on launch. But in the way I'm looking at this that's fine. If the flag gets set to false after shutting down a second screen reader and the first one is working fine I won't have to relaunch programs. And if I run the program to reset the flag after closing the second screen reader it will be true for any programs I launch thereafter. So the trick would be to run the program as soon as we shut down the second screen reader, which is what I would do because otherwise I'll forget. And after resetting the flag I can broadcast a system message that the flag was changed. So all those wild little party animal programs will be notified. Regards, Tom On 11/8/2017 10:37 AM, Steve Jacobson via Talk wrote: Tom, Given my tendency to believe that the more complex something is, the more likely it will cause problems, I think it might be useful to be able to simply reset the screen reader flag upon demand as you suggest. While I don't see any flaws in your logic, I would caution that there could be applications that only check the screen reader flag when they start. In other words, resetting the flag to true might not solve all problems. One would assume that the operating system would know the flag was reset, and that might resolve most of the problems that would arise, though. I have no knowledge of how that flag is checked so this is all speculation which is also dangerous. Thanks for this information. Best regards, Steve Jacobson -Original Message- From: Talk [mailto:talk-bounces+steve.jacobson=visi@lists.window-eyes.com] On Behalf Of Tom Kingston via Talk Sent: Wednesday, November 08, 2017 8:52 AM To: Olusegun -- Victory Associates LTD, Inc. via Talk Cc: Tom Kingston Subject: Re: A little tech tip on Windows and screen readers. Olusegun, John is right. The program I wrote was just to confirm the problem. But I read your message a while ago and have been pondering it while luxuriating in Peet's coffee. That's my latest low-tech discovery. Highly recommended. (smile) WARNING! If you don't want to geek freak out close this message now! Three ... two ... one ... lift off! Solving the screen reader flag problem programmatically is possible, but not very practical. A program that would take care of it automatically would need to be loaded at startup, wait a little while, and check to see if the flag is true. Then it would know your screen reader is running. (No assumptions is the golden rule in programming.) If so it would then have to begin a process loop. Here's what that loop would have to do. 1. Enumerate all the running processes to see if a screen reader is loaded. I might be able to query for Window-Eyes, NVDA, and JAWS individually. 2. Get the screen reader flag status and see if it's false. 3. If both conditions are true then reset the flag to true. 4. Put the program to sleep for whatever time is determined to be reasonable for how often the check is performed so it doesn't bog down the system but doesn't wait too long before resetting the flag. 5. Iterate the loop and repeat the above steps. This is done automatically but it is a process nonetheless. Checking the flag is a simple function, but building a construct with all running processes isn't exactly a small task. It's more or less a slimmed down shell of the Windows task manager without a UI. So I gave this idea a thumbs down. Then a more practical approach came to mind. It would be a program you could run to see if the screen reader flag is true and prompt you to enable it if not. Yeah ... but, I thought, this really gets back to the original solution of remembering to reload your screen reader because you'd have to remember to run the program. But wait! I thought. It would be beneficial because reloading our screen readers while some programs are running requires us to close and reload the program due to the preparations our screen reader does for that program when it loads. For example, when I'm in my programming developer writing a program I cannot reload NVDA. It cannot see the caret when I do so. It has to find it when the program launches. And I've had to close and reload other programs after reloading my screen reader because some things stop working. Again, screen readers sometimes have to see the program launch in order to work properly with them. Seeing the window come into focus isn't always enough. So, provided that our screen reader has recovered to a fully functional state after having to load another screen reader to get there this would eliminate the need to reload it to reset the screen reader flag. Let me know if anyone sees any flaws in my logic. Regards, Tom On 11/7/2017 10:19 PM, Olusegun -- Victory Associates LTD, Inc. via Talk wrote: Tom, I like the geeky nature of y
Re: A little tech tip on Windows and screen readers.
Steve, Good point. I have no idea why screen reader developers never considered this and just checked the flag from time to time. Perhaps it's one of those things that just fell through the cracks. As for Narrator? Most of the benefits we reap from the flag are from Windows itself. So they no doubt have another internal flag. The only program I know of that I assume must use the flag is the Jarte word processor. So anyone who has that could see if it's not in screen reader mode when loaded with Narrator. Regards, Tom On 11/8/2017 10:13 AM, Steve Jacobson via Talk wrote: 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:talk-bounces+steve.jacobson=visi@lists.window-eyes.com] On Behalf Of Tom Kingston via Talk Sent: Tuesday, November 07, 2017 1: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 a
RE: A little tech tip on Windows and screen readers.
Tom, Given my tendency to believe that the more complex something is, the more likely it will cause problems, I think it might be useful to be able to simply reset the screen reader flag upon demand as you suggest. While I don't see any flaws in your logic, I would caution that there could be applications that only check the screen reader flag when they start. In other words, resetting the flag to true might not solve all problems. One would assume that the operating system would know the flag was reset, and that might resolve most of the problems that would arise, though. I have no knowledge of how that flag is checked so this is all speculation which is also dangerous. Thanks for this information. Best regards, Steve Jacobson -Original Message- From: Talk [mailto:talk-bounces+steve.jacobson=visi@lists.window-eyes.com] On Behalf Of Tom Kingston via Talk Sent: Wednesday, November 08, 2017 8:52 AM To: Olusegun -- Victory Associates LTD, Inc. via Talk Cc: Tom Kingston Subject: Re: A little tech tip on Windows and screen readers. Olusegun, John is right. The program I wrote was just to confirm the problem. But I read your message a while ago and have been pondering it while luxuriating in Peet's coffee. That's my latest low-tech discovery. Highly recommended. (smile) WARNING! If you don't want to geek freak out close this message now! Three ... two ... one ... lift off! Solving the screen reader flag problem programmatically is possible, but not very practical. A program that would take care of it automatically would need to be loaded at startup, wait a little while, and check to see if the flag is true. Then it would know your screen reader is running. (No assumptions is the golden rule in programming.) If so it would then have to begin a process loop. Here's what that loop would have to do. 1. Enumerate all the running processes to see if a screen reader is loaded. I might be able to query for Window-Eyes, NVDA, and JAWS individually. 2. Get the screen reader flag status and see if it's false. 3. If both conditions are true then reset the flag to true. 4. Put the program to sleep for whatever time is determined to be reasonable for how often the check is performed so it doesn't bog down the system but doesn't wait too long before resetting the flag. 5. Iterate the loop and repeat the above steps. This is done automatically but it is a process nonetheless. Checking the flag is a simple function, but building a construct with all running processes isn't exactly a small task. It's more or less a slimmed down shell of the Windows task manager without a UI. So I gave this idea a thumbs down. Then a more practical approach came to mind. It would be a program you could run to see if the screen reader flag is true and prompt you to enable it if not. Yeah ... but, I thought, this really gets back to the original solution of remembering to reload your screen reader because you'd have to remember to run the program. But wait! I thought. It would be beneficial because reloading our screen readers while some programs are running requires us to close and reload the program due to the preparations our screen reader does for that program when it loads. For example, when I'm in my programming developer writing a program I cannot reload NVDA. It cannot see the caret when I do so. It has to find it when the program launches. And I've had to close and reload other programs after reloading my screen reader because some things stop working. Again, screen readers sometimes have to see the program launch in order to work properly with them. Seeing the window come into focus isn't always enough. So, provided that our screen reader has recovered to a fully functional state after having to load another screen reader to get there this would eliminate the need to reload it to reset the screen reader flag. Let me know if anyone sees any flaws in my logic. Regards, Tom On 11/7/2017 10:19 PM, Olusegun -- Victory Associates LTD, Inc. via Talk wrote: > Tom, I like the geeky nature of your post. I thought you had mentioned that > you wrote a program to solve the problem. Is the program up for sale? If > yes, how can I get it to snuggle up in my hands and at what cost? > > Thanks for sharing and for making me a bit more geekier than I deserve! > > Sincerely, > Olusegun > Denver, Colorado > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > ___ > 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/tom.kingston%4 0charter.net. > For subscription options,
RE: A little tech tip on Windows and screen readers.
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:talk-bounces+steve.jacobson=visi@lists.window-eyes.com] On Behalf Of Tom Kingston via Talk Sent: Tuesday, November 07, 2017 1: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 necessa
Re: A little tech tip on Windows and screen readers.
Olusegun, John is right. The program I wrote was just to confirm the problem. But I read your message a while ago and have been pondering it while luxuriating in Peet's coffee. That's my latest low-tech discovery. Highly recommended. (smile) WARNING! If you don't want to geek freak out close this message now! Three ... two ... one ... lift off! Solving the screen reader flag problem programmatically is possible, but not very practical. A program that would take care of it automatically would need to be loaded at startup, wait a little while, and check to see if the flag is true. Then it would know your screen reader is running. (No assumptions is the golden rule in programming.) If so it would then have to begin a process loop. Here's what that loop would have to do. 1. Enumerate all the running processes to see if a screen reader is loaded. I might be able to query for Window-Eyes, NVDA, and JAWS individually. 2. Get the screen reader flag status and see if it's false. 3. If both conditions are true then reset the flag to true. 4. Put the program to sleep for whatever time is determined to be reasonable for how often the check is performed so it doesn't bog down the system but doesn't wait too long before resetting the flag. 5. Iterate the loop and repeat the above steps. This is done automatically but it is a process nonetheless. Checking the flag is a simple function, but building a construct with all running processes isn't exactly a small task. It's more or less a slimmed down shell of the Windows task manager without a UI. So I gave this idea a thumbs down. Then a more practical approach came to mind. It would be a program you could run to see if the screen reader flag is true and prompt you to enable it if not. Yeah ... but, I thought, this really gets back to the original solution of remembering to reload your screen reader because you'd have to remember to run the program. But wait! I thought. It would be beneficial because reloading our screen readers while some programs are running requires us to close and reload the program due to the preparations our screen reader does for that program when it loads. For example, when I'm in my programming developer writing a program I cannot reload NVDA. It cannot see the caret when I do so. It has to find it when the program launches. And I've had to close and reload other programs after reloading my screen reader because some things stop working. Again, screen readers sometimes have to see the program launch in order to work properly with them. Seeing the window come into focus isn't always enough. So, provided that our screen reader has recovered to a fully functional state after having to load another screen reader to get there this would eliminate the need to reload it to reset the screen reader flag. Let me know if anyone sees any flaws in my logic. Regards, Tom On 11/7/2017 10:19 PM, Olusegun -- Victory Associates LTD, Inc. via Talk wrote: Tom, I like the geeky nature of your post. I thought you had mentioned that you wrote a program to solve the problem. Is the program up for sale? If yes, how can I get it to snuggle up in my hands and at what cost? Thanks for sharing and for making me a bit more geekier than I deserve! Sincerely, Olusegun Denver, Colorado --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ 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/tom.kingston%40charter.net. 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
RE: A little tech tip on Windows and screen readers.
Olusegun, if I understood Tom's post correctly, his programs checks to see if the flat is on or off. I don't think it turns the flag on. If I'm wrong, somebody correct me. At 10:19 PM 11/7/2017, you wrote: Tom, I like the geeky nature of your post. I thought you had mentioned that you wrote a program to solve the problem. Is the program up for sale? If yes, how can I get it to snuggle up in my hands and at what cost? Thanks for sharing and for making me a bit more geekier than I deserve! Sincerely, Olusegun Denver, Colorado --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ 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/jschwery%40centurylink.net. 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 John ___ 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
Re: A little tech tip on Windows and screen readers.
Hello Tom, Thanks for sharing this very interesting fact. Maybe that's how we are recognised when we try to update to Windows 10. -Original Message- From: Tom Kingston via Talk Sent: Wednesday, November 8, 2017 3:54 AM 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/peter.chinpk%40gmail.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
RE: A little tech tip on Windows and screen readers.
Tom, I like the geeky nature of your post. I thought you had mentioned that you wrote a program to solve the problem. Is the program up for sale? If yes, how can I get it to snuggle up in my hands and at what cost? Thanks for sharing and for making me a bit more geekier than I deserve! Sincerely, Olusegun Denver, Colorado --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ 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
Re: A little tech tip on Windows and screen readers.
Pam, It's how Windows or other programs know if you're running a screen reader or not. They can then choose to operate differently if they want to support screen readers. The point I was trying to make, and obviously failed at in this instance, is what I concluded with. If you have a problem with one screen reader and launch another, solve the problem for the first and then close the second, the screen reader flag is false (off) in Windows. Then you should close the first, presumably your main screen reader, and launch it again to turn that flag back on because Windows and some programs do things differently when they see that flag waving. Sorry if it was too geeky. Hth, Tom On 11/7/2017 8:57 PM, Pamela Dominguez via Talk wrote: What is this flag true and false stuff? This is the first time I have heard of such a thing. Pam. -Original Message- From: Tom Kingston via Talk Sent: Tuesday, November 07, 2017 2: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
Re: A little tech tip on Windows and screen readers.
What is this flag true and false stuff? This is the first time I have heard of such a thing. Pam. -Original Message- From: Tom Kingston via Talk Sent: Tuesday, November 07, 2017 2: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/geodom%40optonline.net. 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 email has been checked for viruses by AVG. http://www.avg.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.c
RE: A little tech tip on Windows and screen readers.
Tom, That is a little geeky, but still interesting. Thanks for sharing. -Original Message- From: Talk [mailto:talk-bounces+robin.van.lant=key@lists.window-eyes.com] 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
