Hi Michael, I'll freely admit I don't have all the answers here as my understanding of how it all works is pretty basic at best. However, what I can say is the primary problem with your assumptions is that you have made some false conclusions on how it works that are false and it has given you an unreasonable expectation that the problem is easily resolved.
To begin with the main reason standards and standard controls are important is because no two screen reader developers have to duplicate the same work making an application accessible. Therefore the ideal situation is one in which the application is written using all standard controls and interfaces known to all screen readers. Whenever a developer deviates from that standard a screen reader developer then has to spend lots of time and money trying to make the application and its custom controls work with the screen reader which is no trivial task. Therefore the current accessibility paradigms that it is up to the developer of the application to use standard controls and user interfaces thus placing responsibility of access on the developer of the program. That is not such a bad thing. On Linux the GTK+ toolkit has been made fully accessible, is tightly integrated with at-spi2, so in theory any Linux application developer using GTK+ will have a reasonable amount of access with Orca. On Mac OS X the standard graphics toolkit, Cocoa, has been made accessible so any Mac application using Cocoa will work with VoiceOver out of the box. Similar efforts are under way on Windows with UI Automation and the Windows Foundation Classes. Bottom line, these days accessibility frankly is not the job of the screen reader, but is increasingly the responsibility of the application developer using standard toolkits and controls. However, as I understand your suggestion every screen reader should be designed to support every possible non-standard control out there. The big problem with that is simple. There isn't enough money or interest in trying to support every custom non-standard control in existence. Especially, given that we are a minority market, and the application in question may only be of benefit to or will be used by a small minority inside an existing minority. Therefore we are talking about a titanic effort on the part of screen reader developers for little money. Besides you seem to have missed the obvious problem is that a custom control is custom. It is something a screen reader is unlikely to know what it is, and if a screen reader developer doesn't know it exists he can't program the screen reader to handle that control. He would have to be informed of the controls existence in order to support it, and in a market where millions of custom controls are likely to exist it is effectively impossible to support them all. Plus even if screen reader A were able to support every custom control out there the same work would have to be performed on screen reader B to have the exact same support. Therefore the best and most ideal situation is one in which the application uses standard controls that are known to exist. Cheers! On 1/9/15, Michael Gauler <michael.gau...@gmx.de> wrote: > Ok, I got that... > But I think that since Windows was created, there were always developers of > > software who did not necessarily use standard controls or API > communications. > If this problem is technically that old, why does look it like (from the > point of view from the end user of a screen reader) that the screen reader > developers seem to be incapable of adding support for more non standard > controls? > I mean, I don't know how designing controls work. > But non standard controls go back to the Windows 95 era. > Seriously, Java, Shockwave formerly Macromedia Director or Flash are known > technologies, right? > If anyone (professional) developers can get access to parts of that > technology, then there surely should be a way of adapting the screen reader > > to handle non standard controls, right? > I mean we or our screen reader developers can't force everyone to solely use > > standard controls, even if Microsoft might like that or not. > JAWS for example is one of the oldest commercial screen readers which still > > exists today. > And there are lots of blind users who have to deal with non standard > controls at work or at home. > This problem is known. > Obviously it would take a long time to make every control element > accessible, that is surely true. > But as I said, everyone knows for example what Flash or Silverlight or Java > > and a few other partially accessible are and that there might be a certain > demand in making such things accessible. > > And about the Video Intercept drivers, how limited is its effectiveness if > it (in theory) can get more data than the Windows API might give the screen > > reader for a certain application? > > > --- > Gamers mailing list __ Gamers@audyssey.org > If you want to leave the list, send E-mail to > gamers-unsubscr...@audyssey.org. > 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/gamers@audyssey.org. > If you have any questions or concerns regarding the management of the list, > please send E-mail to gamers-ow...@audyssey.org. > --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. 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/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
