Re: ATK ,GTK...

[Bill Haneman <Bill Haneman Sun COM>]

>  So let me get this straight. ATK is just the definition of an
>interface and GAIL implements this interface. So does GAIL take gtk data
>and convert it to be accessed through the ATK interface? That is, does the
>Assistive Technology (Screen reader, etc...) access a GUI's data through
>the ATK interface without any knowledge of the GUI itself?

Yep.

>If so then ATK could become an interface standard for AT
>devices/applications to access and get information on a GUI.

It's certainly an interface "definition", and an open one.  Whether it goes from "spec" 
to "standard" (in the absence of a standards body ;-) probably has more to do with how 
widely it is adopted than anything else.

The reason that ATK is not going to be the "standard" for adaptive technology 
devices/apps is that ATK is an in-process interface, and it also includes some API that 
is intended to be called from the application and not the AT (for instance, many of the 
"setter" methods for accessibility properties.  The API that AT will use is defined by 
the SPI, whether or not the GUI uses ATK internally.

The SPI maps very closely onto ATK, so there is not a big difference other than the fact 
that the SPI will be accessed by AT via a shared library that communicates with multiple 
applications that bridge to it.  (Note that applications that are unable to use the 
shared library's C bindings can implement the SPI's CORBA IDL via an alternate means if 
they choose to do so).

>Is SPI going to be the solution to access data from a GUI that does not
>have an ATK interface? Looking at the diagram it looks like it will rely
>on intercepting events sent to and from the GUI.

The SPI applies for all GUIs, whether they use ATK internally or some other, similar 
accessibility API (for instance, Java apps using the Java Accessibility API).  This means 
that ATs will interact with accessible applications the same way regardless of whether 
they use ATK or some similar accessibility interfaces at the toolkit level.

There are two aspects to this SPI: there is a central accessibility broker that moderates 
requests to enumerate the accessible applications on the desktop, and relay event 
notifications from the GUI to listening AT.  However once an AT is notified of an 
application's existence the AT can and will query the application directly via the other 
SPI interfaces.  Thus the SPI includes both broker functionality and application 
interrogation.


-Bill


>On Fri, 8 Jun 2001, Bill Haneman wrote:
>
>> 
>> >  I'm browsing around these accessibility docs and I'm a little 
>> confused.
>> >Are there two projects going on with gnome for accessiblity? An 
>> addition
>> >to GTK to make applications using GTK accessible, and another project 
>> (ATK
>> >I think it's called?) to make applications that don't use GTK 
>> accessible?
>> >Am I correct? Thanks
>> 
>> Not quite ;-)
>> 
>> ATK is a set of interface definitions and wrappers defining 
>> accessibility.  ATK is not GTK-specific, but ATK does define the 
>> accessibility interfaces which GTK uses.
>> 
>> In turn, the actual implementation of those interfaces on behalf of the 
>> GTK+ widgets is in a project called GAIL, which is dynamically loadable 
>> by a GTK+ application.
>> 
>> Thus:
>> 
>> GTK+ depends on the accessibility interfaces in ATK (thus ATK "defines" 
>> accessibility for GTK+).
>> 
>> ATK itself has no dependencies on GTK+, thus other toolkits could still 
>> use ATK as their accessibility interface definition and accessibility 
>> API.
>> 
>> The actual widget-specific code that implements those interfaces lives 
>> in another module which is dynamically loadable (GAIL).  If GAIL is not 
>> loaded, GTK+ widgets will have a default accessibility implementation 
>> that basically returns "null" information though it nominally conforms 
>> to the ATK API.  
>> 
>> ATK depends on glib, so any toolkits wishing to implement ATK as their 
>> accessibility interfaces will need to link to glib.
>> 
>> Status:  ATK is basically complete/frozen, GAIL is under active 
>> development, somewhere around 35% complete.
>> 
>> There is another set of interfaces, still being finalized, called the 
>> accessibility Service Provider Interface (SPI).  These interfaces are 
>> used by out-of-process clients to obtain accessibility information about 
>> running applications.  (ATK can't be used for this since ATK is an 
>> in-process interface, and can only be used directly within the 
>> application's own process space).  This SPI can be implemented by any 
>> toolkit.  In the case of GTK+, the internal ATK interfaces are exported 
>> to the SPI via the "Accessibility Bridge".
>> 
>> Two diagrams of interest:
>> 
>> http://developer.gnome.org/projects/gap/presentations/GUADEC/gnomeaccess
>> architecture.html
>> 
>> http://developer.gnome.org/projects/gap/tech-docs/SPIBlockDiagram.png
>> 
>> Regards,
>> 
>> -Bill
>> 
>> > Garrett Banuk
>> >
>> >
>> >_______________________________________________
>> >gnome-accessibility-list mailing list
>> >gnome-accessibility-list gnome org
>> >http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>> 
>> ------
>> Bill Haneman x19279
>> Gnome Accessibility / Batik SVG Toolkit
>> Sun Microsystems Ireland 
>> 
>> 
>> _______________________________________________
>> gnome-accessibility-list mailing list
>> gnome-accessibility-list gnome org
>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>> 
>
>
>_______________________________________________
>gnome-accessibility-list mailing list
>gnome-accessibility-list gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

------
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland