Hi Michael, I'm not an expert on how the Jaws video intercept driver works, but apparently it somehow works in tandem with the existing Windows APIs to provide spoken feedback to what is on screen. The video intercept driver Jaws supplies is not where Jaws gets most of its information though. Let's take Internet Explorer as an example.
When you fire up Internet Explorer there is an accessibility API, MSAA, acting as a bridge between the application and your screen reader. Jaws or whatever the screenreader is you are running takes the information handed to it from MSAA and converts it to spoken feedback or braille. Further more the navigation keys like f to jump to the nearest form field, h to jump to the next header, t for next table, etc are a part of the MSAA framework that screen readers can tie into to help get around web pages better. As I said I'm not real clear on what exactly the video intercept does, but there are some pretty clear cases when MSAA or similar is not being used Jaws doesn't see anything but a blank screen. For instance, Direct3D, OpenGL, and SDL all have print commands to print text to the window to display scores, menus, and other such textual data in game but no screen reader recognizes it as text. I'm speculating that is because none of those graphics APIs goes through the standard channels when presenting that information to the screen. As for the issue of controls it is pretty much as you said. Jaws, Window-Eyes, etc come with a standard database of controles that the developer knows about, that should come with every application, and if an application uses something non-standard that database has to be updated by comparing it to something the screen reader knows about. /For example, on Linux some graphical apps have a spin box or spin control. Since this is very uncommon for MS Windows apps Jaws probably won't have a clue what it is. You might have to asign it to a radio button which might be close enough for Jaws to interact with and read the status of the control. Make sense? Which brings me to my final point. I've looked at NVDA pretty indepth and from what I can tell it primarily gathers information through standard Windows Events, through MSAA, and standard Windows API methods and then presents it to you via speech or braille. It doesn't require video intercept drivers or anything like that to get access to Firefox, Internet Explorer, MS office, Windows Mail, Notepad, or any of the other applications I use with it and NVDA is is nearly as good as the commercial screen readers. So I know that the majority of info doesn't come from the video intercept. On 12/28/11, Michael Gauler <[email protected]> wrote: > Hi thomas, > I have a very important question about this topic. > I'll use JAWS as an example here, because I am not sure what other screen > readers do. > You said that any program which uses the Windows API is theoretically > readable with a screen reader because the program "broadcasts" some > information through the API which the screen reader can optain. > But of course programmers can allways do without the main API of any given > operating system. This might cause "confusion" for a screen reader as you > said. > But now there is my question. > A screen reader should be able to read most of the information currently on > screen, at least in theory. > When JAWS is first installed on a PC, a program wants to install "Video > Intercept" which adds a "virtual?" secondary graphics card into the control > panel. > Video Intercept should be able to get all information from the "real" > graphics card to the screen reader. > Even if a program doesn't use non Windows API controls, it should be > possible to find non standard controls and recognice them via Video > Intercept. > Even if controls are different, the basic principles still apply: selecting > entries from various lists, radio buttons checkboxes or any and all forms of > fields to enter any form of text... > So, the question is why do create a secondary Graphics card (probably a > virtual one) when most information gained from it seems to be unused all the > time, or does JAWS (or any other screen reader) need an update to the list > of standard controls it knows? > There are so many forms of editable fields in forms or other programs where > you can enter text, but you have to tell your screen reader manually that it > is an "edit" (in JAWS via your the configuration Manager). > I know that the list of known controls can be seen via the Insert+7 key > combination, but as far as I can remember (my first long term contact with > JAWS was before JAWS 4.0), this list has not seen many changes since that > time, and it can't be good this way... > > > --- > Gamers mailing list __ [email protected] > If you want to leave the list, send E-mail to > [email protected]. > You can make changes or update your subscription via the web, at > http://mail.audyssey.org/mailman/listinfo/gamers_audyssey.org. > All messages are archived and can be searched and read at > http://www.mail-archive.com/[email protected]. > If you have any questions or concerns regarding the management of the list, > please send E-mail to [email protected]. > --- Gamers mailing list __ [email protected] If you want to leave the list, send E-mail to [email protected]. You can make changes or update your subscription via the web, at http://mail.audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/[email protected]. If you have any questions or concerns regarding the management of the list, please send E-mail to [email protected].
