- From: <peter.b.l.meijer@philips.com>
- Date: Thu, 2 Dec 1999 23:20:16 +0100
- To: <w3c-wai-ua@w3.org>
- Cc: <schwer@us.ibm.com>
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 Thursday, 2 December 1999 17:20:26 UTC