|
Hi, While it is true that HAL, JAWS, System Access,
Window-Eyes and ZoomText all get data by simulating a video driver and,
excepting System Access, inserting themselves into the driver chain, this
technique is also the cause of much of the instability one experiences when
using a Windows based screen reader. I'm quite new to gnome and orca but have
discussed the gnome accessibility API with Peter and others for quite a number
of years now. While video hooking can provide a screen reader with a
nasty, non-standard and potentially dangerous way of getting information from
non-compliant applications, the method causes incompatibility with different
brands of hardware, different screen resolutions and different color schemes.
Thus, a user will get different results on different computers and a whole lot
of time gets spent by the authors of the Windows screen readers trying to
handle compatibility problems rather than actual access to programs people
need. These techniques also cause some potentially nasty security
risks. If I cared to, I could write you a quick and dirty JAWS script that
will log all of the user names and passwords that a person uses on their
computer. Then, when IE gets launched, the scripts can email this information
to most any address out there. The gnome accessibility API, while not perfect, actually
provides a relatively generic set of methods to handle some of the highly
contextual information that the Windows products get from the various DOMs out
there. As I said at the start, I'm very new to working with gnome, orca and
the accessibility API and I've been spending the past couple of weeks reading,
studying and trying to move up the learning curve as fast as I can so I can't
say with any certainty how extensive the support can be but, just reading API
documentation, I can say that it's years ahead of MSAA and the Macintosh
accessibility thing. User interface automation from Microsoft offers some very
interesting ways to derive accessibility information from applications but no one
has really embraced it and most programs that use it are demos in which
anything can be made to look really good. Have fun, cdh -----Original Message----- From: orca-list-bounces gnome org
[mailto:orca-list-bounces gnome org] On Behalf Of Nick Adamson Sent: Thursday, August 16, 2007 3:08 PM To: Peter Korn; orca-list gnome org Subject: Re: [orca-list] some programmers want to
contribute to orca. Hi List and Peter. Apologies, I meant to send the below email to the list
rather than peter directly. ----- Original Message ----- From: "Nick Adamson" <Nick NDAdamson com> To: "Peter Korn" <Peter Korn Sun COM> Sent: Thursday, August 16, 2007 7:59 PM Subject: Re: [orca-list] some programmers want to
contribute to orca. > Hi Peter. > > I have found this topic quite interesting. > > I've just started developing under Linux having been
in the windows world > for the last 5 years. > > ICE, www.zeroc.com
seems a very interesting technology as a multi platform > IPC middleware. > > Back in the past I have spent some time working on
windows screen readers > and wonder if any of the ideas behind the way they
work are possible in > Gnome. For example all of the big 3 windows screen
readers, (Hal, Jaws and > Win eyes,) provide hooks in to the display drivers
for windows. The major > benefits to this are that the main application
developers only need to > think about accessibility if there doing something
non-standard. also they > all use Document object models, (DOM) interfaces to
software and off > screen models. to get an overall picture and
representation of the screen > layout. > > I have know idea how Linux or Gnome do the display
drivers and the > different levels of abstraction between the hardware
drivers and end > application level. > > Just some thoughts and musings of a newbie to Linux
and developing under > Gnome. > > Cheers. > nick. > > > ----- Original Message ----- > From: "Peter Korn"
<Peter Korn Sun COM> > To: "Halim Sahin"
<halim sahin t-online de> > Cc: <orca-list gnome org> > Sent: Thursday, August 16, 2007 6:51 AM > Subject: Re: [orca-list] some programmers want to
contribute to orca. > > >> Hi Halim, gang, >> >>> Hi, >>> On Mi, Aug 15, 2007 at 10:53:06 +0200, orca yokoy de wrote: >>> >>>> no, it is not a joke. >>>> AT-SPI is not used by all access
technologies. >>>> >>> >>> Which other access technologies you are
talking about? >>> >>> >>> Halim >> >> >> AT-SPI, the Assistive Technology Service
Provider Interface, specifies >> the information that is provided by accessible
applications to assistive >> technologies (and the questions ATs can ask of
apps). Our >> implementation of AT-SPI uses CORBA for
interprocess communication (the >> AT lives in one process, the app another, so we
need some form of >> interprocess communication). >> >> CORBA is an object based interprocess
communication mechanism (the >> Common Object Request Broker Architecture). The
user interface elements >> in an applications are represented by
'Accessible' objects, these >> objects have methods, and CORBA allows an AT to
make remote, >> inter-process method calls on these objects
(e.g. to ask an accessible >> for its name, its role, etc.). >> >> In order to handle all of the potential issues
that can arise with >> inter-process communication around objects,
CORBA is fairly large and >> complex. It has to handle the case when the
remote object goes away, >> when a method call fails, etc. etc. >> >> Memory constrained environments - like the OLCP
and the Nokia N800 - >> don't include CORBA (whereas many desktop
systems like Ubuntu and >> Solaris do). So, if we are to bring assistive
technology support to >> things like the OLCP and Nokia N800, we need to
address this situation. >> >> One idea is to see whether we can slim down the
CORBA implementation for >> OLCP/N800, on the assumption that AT-SPI may not
need everything that >> CORBA provides. Another idea is to move do a
different inter-process >> communication mechanism (and the candidate
choice here is D-BUS, which >> has roots in DCOP and the KDE desktop). >> >> The big, not fully answered question, is whether
a D-BUS implementation >> of AT-SPI can do everything we need. Recent
news from Trolltech labs >> (the folks behind Qt, the main GUI toolkit for
KDE) sounds promising on >> this front, but I believe a little more
investigation and testing is >> needed before we can be sure this will work for
us. >> >> On a related note, I have repeatedly heard the
suggestion of "moving to >> IAccessible2" for UNIX. To quote the
character Inigo Montoya from the >> movie The Princess Bride, "I do not think
that means what you think it >> means." IAccessible2 is a port of AT-SPI
(or more specifically, the UNO >> Accessibility API in OpenOffice.org) to
Windows. More precisely, it is >> a port of those portions of the UNO
Accessibility API which weren't >> already in MSAA (Microsoft Active Accessibility,
the fairly simplistic >> and primitive accessibility API Microsoft
introduced in 1997). Thus, >> IAccessible2 is not a complete API, but rather
is an extension of MSAA. >> Also, like MSAA, IAccessible2 uses the Microsoft
interprocess >> communication mechanism 'COM' (Component Object
Model). COM doesn't >> exist on OLPC or N800. While I believe there
are ports of COM to UNIX, >> nobody I know of is suggesting implementing COM
on UNIX an alternative >> to CORBA for accessibility purposes. >> >> Because toolkits like GTK+ and Qt have been
ported to Windows, and >> because IAccessible2 is gaining some traction on
the Windows platform >> with JAWS and WindowEyes providing support for
it in their screen >> readers, exposing accessibility information for
GTK+ and Qt applications >> on Windows via IAccessible2 makes a lot of
sense. Since IAccessible2 is >> derived from the UNO Accessibility API, which
itself is expressed in >> AT-SPI on UNIX, having cross platform apps be
accessible on both UNIX >> and Windows via what is essentially the same API
(though different >> inter-process communication implementation)
makes a lot of sense. >> >> >> To the question Halim asked, about what AT
supports a D-BUS >> implementation of AT-SPI, I believe Trolltech
labs a fork of Dasher that >> uses it. As the GNOME Dasher makes fairly
simple and limited use of >> AT-SPI, this is a natural first AT to test out.
But as it is nowhere as >> heavy a user of AT-SPI as something like Orca,
this port doesn't >> definitely answer questions about whether we can
do everything we need >> to in a D-BUS based AT-SPI. I know there are other,
KDE AT tools, but I >> don't think any of them make heavy use of the
API either. All of them >> pre-date Trolltech's work in this area, and I
haven't seen any mention >> of them being updated. >> >> >> Another important facet to this whole discussion
is the question of >> whether we actually need to fork/port AT to use
the D-BUS >> implementation. The Accerciser project
introduced a Python abstraction >> layer to CORBA AT-SPI. Moving our Python-based
AT (like Orca) to this >> abstraction layer would allow us to substitute
something else for CORBA >> (e.g. D-BUS), without needing to
fork/port/modify Orca at all. Orca >> could use CORBA-based AT-SPI on those platforms
where that approach made >> sense, and something else (e.g. D-BUS) on
others, where that was a >> better choice. CORBA and AT-SPI have a lot
going for them. They are >> tested and proven technologies. It may make
sense to stay on CORBA for >> a while in the desktop world, even as we move to
something else in >> memory constrained environments like OLCP and
N800. >> >> >> I hope this helps clear up a lot of the
questions and confusion around >> these topics >> >> >> Regards, >> >> Peter Korn >> Accessibility Architect, >> Sun Microsystems, Inc. >> _______________________________________________ >> Orca-list mailing list >> http://mail.gnome.org/mailman/listinfo/orca-list >> Visit http://live.gnome.org/Orca
for more information on Orca >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.11.13/946
- Release Date: >> 10/08/2007 15:50 >> >> > _______________________________________________ Orca-list mailing list http://mail.gnome.org/mailman/listinfo/orca-list Visit http://live.gnome.org/Orca
for more information on Orca __________ NOD32 2465 (20070816) Information __________ This message was checked by NOD32 antivirus system. |