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/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
