- From: Mickey Quenzer <mickeyq@earthlink.net>
- Date: Tue, 6 Feb 2001 06:59:55 -0800
- To: <w3c-wai-ua@w3.org>
This messsage was sent fromAaron Leventhal <aaronl@chorus.net> I thaught that it was interesting. Maybe we should envite Aaron Leventhal to join our team! He manages the Mozilla accessibility listserv! ******* MQ ******* ----- Original Message ----- From: "Aaron Leventhal" <aaronl@chorus.net> To: <mozilla-accessibility@mozilla.org>; <ocularis-devel@lists.sourceforge.net> Sent: Wednesday, January 31, 2001 8:52 PM Subject: Re: (Access-Mozilla) Re: Accessibility API plans and cross-reference > Phil, > > Java Accessibility is cross-platform, unless you consider it it's own > platform, and not really part of the native platform. It's not really a > possibility for Netscape to use Java Accessibility, which is built on > our own cross-platform foundation (NSPR - Netscape Portable Runtime, the > XPToolkit - cross platform toolkit, and the XPFE - Cross Platform Front > End). It isn't an option to support accessibility by using native > widgets, because our XPFE is written in XML (XUL), Javascript and CSS. > In addition, only JAWS for Windows supports Java Accessibility. In MSAA > there are more vendors supporting it - GW Micro (WindowEyes), ZoomText, > and I think Dragon Dictate all utilize MSAA. > > That said, the reason for our comparison table between MSAA & Java > Accessibility is so we can see, they really only have 1/3 of the states > and roles being similar between the two APIs! I think it's a shame and > a waste of developers time to have each accessibility API represent a > whole new learning curve. It would be nice if the accessibility APIs on > different platforms at least utilized a common set of roles and states. > At least some code sharing could be utilized then, in the form of data > associated with the different widgets. > > Now we have a new challenge - the Sun time is developing the industry's > 3rd accessibility API, Gnome Accessibility. I think if a new > accessibility API is created, it should be flexible enough to support > multiple widget sets (hopefully without being over-engineered). I think > if IBM teamed with Sun, the Trace Center, KDE and vendors interested in > Linux, to develop an open source Accessibility API for Linux/UNIX, it > could have momentum to move forward. The time to get this moving is at > the Linux accessibility conference at CSUN. > > Aaron > > > > Phill.Jenkins@smtp2.chorus.net wrote: > > > The Java Accessibility API is cross-platform, but it won\'t work for Windows C++ or GNOME applications, because they are NOT cross-platform. > > I can\'t take Netscape for UNIX and run it on Windows, while I can take Bobby and run it anywhere (Windows, UNIX, OS/2, etc.) Java is running. Netscape & Mozilla are know as running on lots of platforms - multi-platform, but it is not implemented in a cross-platform technology. > > I view it as being ported to run on each platform. So the question Mozilla has, and other applications [very common in IBM and Lotus] that want to run on multiple platforms have, is to which accessibility API do I right to on > > each platform? It would be useful to have a chart showing the platforms and where the APIs exist, it should also include \"standard OS controls\" since they are generally accessible on the specific platform; in other words assistive technologies write to standard controls. It would also be useful to list the assistive technologies that support the accessibility > > APIs. For example, JAWs on Windows supports the Java Accessibility API via the Java Access Bridge; while the IBM Self Voicing Kit supports the Java Accessibility API on any platform that supports Java. > > > > If all the assistive technology vendors got together and created the standard API that they wanted all the OS and app developers to write to, > > then the OS and app developers would want to listen, especially in light of 508 and other regulations. But who has the mandate to heard all the AT vendors together? > > > > > > > > > > >
Received on Tuesday, 6 February 2001 09:59:47 UTC