- From: <schwer@us.ibm.com>
- Date: Wed, 8 Dec 1999 16:06:22 -0600
- To: peter.b.l.meijer@philips.com
- cc: w3c-wai-ua@w3.org
Hi Peter, I am resending this because I sent it before I was done editing it. First off I would like to state that I wrote the OSM for Screen Reader/2 so I understand what you are saying. However, what I am also saying is that there are many screen readers with different OSM architectures. Furthermore, these OSM's become more convoluted as new technology, like the DOM, are made available to reduce the dependency on GUI drawing to OSM reverse engineered architectures. Even more important is the fact that these screen reader vendors feel that the way their specific OSM is designed is a key differentiator from competitors. Some of these like Screen Reader/2 contained things like menu hierarchies. Tying engineered hooks back into these non-standard OSM architecture is a tall order and not one that should be required of user agent developers. Also, there are platforms like UNIX where there are no screen reader products that make use of an OSM. I agree that standardization for what you ask would be nice, however I would prefer to see the W3C WAI group continue to construct heterogeneous accessibility architectures that are not platform dependendent for accessibility. These constructs require considerably less reverse-engineering. The DOM is one example of that type of technology. Rich Rich Schwerdtfeger Lead Architect, IBM Special Needs Systems EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm "Two roads diverged in a wood, and I - I took the one less traveled by, and that has made all the difference.", Frost peter.b.l.meijer@philips.com on 12/02/99 04:20:16 PM To: w3c-wai-ua@w3.org cc: Richard Schwerdtfeger/Austin/IBM@IBMUS Subject: Re: Some comments on conformance levels in UA guidelines draft Rich Schwerdtfeger wrote > Whose OSM? OSM's are screen reader vendor specific and are > not resident on any platform other than OS/2 and Windows. This is in part why I had written > Additional work will be needed to forge this into a solid and > open standard, particularly if we want this as independent from > any particular operating system as possible All operating systems with a GUI have an off-screen model of some sort: there is no way to manage a GUI without it. The model may just not be available for third-party developers of assistive technology to allow for creating a wedge that implements alternative accessible I/O - as needed for screen readers, for instance. The implementation of, and set of hooks into, off-screen models is indeed operating system specific, but the basic visual object structure of a GUI is extremely similar across many platforms (Microsoft Windows, X-Windows on UNIX systems, Mac OS, OS/2, Java OS and so on): you nearly always find menus, icons, window borders (often with maximize, minimize and close gadgets and a title bar), buttons, edit boxes, scroll bars and so forth, soon covering the majority of controls needed to use an application effectively. To make my point as a sighted person: I have never used OS/2, but I'm confident that I can use it within five minutes for basic work. Now let's consider basic menus for some further illustration. It really is not so hard to specify that an off-screen model should contain a copy of the menu hierarchy of the "standard" menus of all active application instances, plus the textual content of menu items, in a way that third-party assistive technology can access that information. The "reference" screen reader for any operating system will for accessibility compliance be required to present all of this information in an accessible form, allowing a blind user to navigate, for any application, its menu hierarchy and select and activate one particular menu item, while the application in turn will be required to create its own menus as "standard" menus for accessibility compliance. (Before sprinkling known exceptions over me: I do not claim to be exhaustive or exact here, I'm merely trying to convey the basic ideas, which may be hard enough.) I think it should not be too difficult to spell out what "standard" means for each of the dozen or so operating systems that we may wish to consider, but yes, it does involve additional work. The main issue really is to specify *that* all "standard" menus must be made accessible by a screen reader in order to meet the UA conformance requirements. (Thus not just the menus of the screen reader itself!) Then the general application developer will know beforehand that simply using "standard" menus is OK and meets the conformance requirements, so that the use of this application in combination with any screen reader that meets the conformance requirements will *guarantee* accessibility (of menus in this oversimplified example). Right now the conformance requirements in the UA guidelines do not seem to fully and clearly address the accessibility of a combination of screen reader with generic application, while that seems the only economic way for making many of the best applications accessible to blind people. It would be rather worrisome if the UA guidelines would implicitly favour "self-contained" accessibility packages by specifying compliance ratings that cannot be properly applied to combinations of screen readers with generic applications (such as mainstream browsers used by the sighted), while the current trend seems to be rather that blind people increasingly prefer using just that. This is, again, why I think a compliance rating based on the current UA guidelines is not in order. Unintentionally, it could appear biased and selective w.r.t. accessibility practices and efforts, by providing a compliance rating only for products that include accessibility provisions "natively". The UA guidelines are at their current stage excellent as an informal checklist, which is highly useful and a major achievement, but I suggest that the UA guidelines are not ready for labelling products through a compliance rating. Best wishes, Peter Meijer The vOICe Internet Sonification Browser http://ourworld.compuserve.com/homepages/Peter_Meijer/eyebrows.htm
Received on Wednesday, 8 December 1999 17:10:51 UTC