Hi Michael, Well, the answer to your question requires a bit of in depth knowledge of how accessibility on your system works, but I'll try and boil it down to something a common person can understand without a great deal of technical knowledge.
To begin with it might be helpful to understand what a screen reader is and what it is not. A lot of screen reader users falsely assume that their screen reader somehow reads the screen and speaks aloud what it sees on screen at the time. That isn't really how it works. In truth your screen reader communicates with the operating system in particular with the Windows API, MSAA, and UI Automation among other things to determine the identity of what is on the screen at any given time. It then speaks aloud whatever information it has managed to discover is on the screen through the various APIs. It all works for the most part because Microsoft has created several standard Windows controls that expose their status and identity through one of a number of APIs. Therefore the way your screen reader usually works is it asks the Windows API, MSAA, or UI Automation what is on the screen, and then one of those APIs will report what information if any has been passed onto it via your application. If the program in question uses standard Windows controls no problem. The API and your screen reader knows what is being shown and it gets spoken. However, if someone chooses to use a non-standard control, an alternative graphics toolkit, or display something on the screen in any other way than through the standard Windows controls the application isn't exposing any information about what is on screen to the various accessibility APIs thus your screen reader hasn't a clue as to what is being shown which brings us to the problem with Dosbox. Dosbox and various other emulators like it display stuff on the screen at a very low level bypassing all the standard Windows controls and any accessibility APIs like MSAA or UI Automation. Dosbox uses a custom graphics library that has absolutely no accessibility, does not engage in two-way communication with your screen reader, thus as far as the screen reader knows the screen is blank or simply unknown. So even though you might have a game that is purely text on screen the emulator, Dosbox, is only displaying a graphical representation of the text and is not passing the contents of the screen onto the Windows API, MSAA, UI Automation, or any other API that your screen reader relies upon for information as to what is being shown on screen. Thus the screen reader can't read what it doesn't know about. About the only way at present for a Windows screen reader to read what is on screen in Dosbox is to perform OCR on it. Jaws, NVDA, and others now have the ability to take a picture of the screen, to perform OCR on that picture, and then read the contents of the screen. While that will work it is slow and clunky which makes using Dosbox inefficient. Now, I am sure someone is about to ask about the video intercept drivers Jaws, Window-Eyes, etc use. Those are a fallback position for screen readers in case the Windows accessibility APIs fail. It is basically an attempt to store the state of the screen in a buffer and brute force determine what is being shown on screen. It is very slow and inefficient and in the end suffers from the same sort of problem as the other methods of determining what is on screen. Dosbox uses non-standard graphics libraries, non standard controls, and Jaws and other screen readers can't tell you what is on screen if it doesn't know what sort of control it is looking at. Therefore as long as Dosbox and other emulators use non-standard controls and do not expose what is on screen there is no realistic way for your screen reader to read the screen. Cheers! On 1/8/15, Michael Gauler <[email protected]> wrote: > Hi Thomas, > I would like to ask a question about the problems with such programs as the > > mentioned Dosbox. > Why is it so difficult for a screen reader to get anything from such a > program? > Shouldn't (in theory) a screen reader be able to get all the information on > > the screen as it is given from a graphic card to the screen or whatever > component actually puts anything on the screen? > If this is not true, what purpose had such things as Video Intercept for > JAWS up to Windows 7? > If I have a program which in theory has access to all (graphical) > information which is currently displayed on the screen, shouldn't a screen > reader be able to read more things as long as you are not running a full > virtual machine or if you are not playing some kind of video where you have > > constantly changing images on screen? > I mean some text DOS games are not that graphically complex like a video or > > some high end animations of mainstream games. > And while we are at it, Dosbox surely wasn't developed Yesterday. > This brings up the question why no screen reader developer seems to have > found a way to read such programs like Dosbox in general. > > > --- > 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://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://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].
