Re: Panel Accessibility (long, but please read) [was Re: PanelStatus - GNOME 2.0]



Peter Williams wrote:
> 
> Hi Sander,
> 
> On Sun, 2001-11-18 at 12:03, Sander Vesik wrote:
> > The problem is - it does not seem all that likely there willbe any
> > accessability patches from anybody but the sun accessability folks, and
> > thus its extremly unlikely that it will be in place for gnome core by 2.0
> > even if it was considerably postponed.
> >
> 
> Is there a primer for people interested in working on accessibility? I'm
> intruiged by the idea, and I could probably find the time to cook up
> quick patches, but I find the whole mess of atk/at-spi/gail/ferret
> pretty confusing. I don't even understand how accessibility is
> implemented in general. Is there something I can read to learn a bit
> more?
> 
> Thanks,
>         Peter

Hi Peter:

As usual documentation is competing with development for cycles...

However there is some material on the Gnome Accessibility Project pages:

http://developer.gnome.org/projects/gap

a guide for (application) developers:

http://developer.gnome.org/projects/gap/guide/gad/index.html

and a little more architectural overview in HTML slides in the
'Presentations' directory:

http://developer.gnome.org/projects/gap/presentations/GUADEC/index.html

check out, if nothing else, the architectural layers diagram:

http://developer.gnome.org/projects/gap/presentations/GUADEC/gnomeaccessarchitecture.html

There needs to be a FAQ for gnome developers or something that explains
how the various CVS modules fit together.

In the meantime, the short version:

We decided to implement accessibility on UI components by defining some
general, abstract interfaces that UI components implement; these
interfaces can be interacted with to get info about the UI component or
to activate it, query it, etc. via means other than mouse, keyboard, or
visual  presentation.

We defined those interfaces in ATK, and all GTK+ widgets can be queried
for their 'accessible' incarnation.  However libatk does not provide
much implementation, it defines the interfaces only; the implementation
lives in a separate loadable library called libgail, and follows a
factory model in which accessible representations of GTK+ widgets are
created on demand.  The widget-specific representations know how to
export the necessary info and behavior from their widgets into the
general ATK API, so clients of ATK need not know details of widget
behavior or API.  Likewise ATK provides the application programmer a
means of explicitly enhancing/setting accessibility properties on
widgets (like associating labels with UI components which they logicall
label, etc.).

In order to work with assistive technologies which help disabled users
interact with the Gnome UI, the uniform accessibility API has to be
exposed to out-of-process clients.  That's the job of various parts of
at-spi, at-spi includes IDL that defines the accessibility APIs used by
assistive technologies, and includes a central service registry (using
bonobo) and 'bridging' code that connects the in-process ATK APIs to the
out-of-process AT-SPI interfaces.

Of course there are other important aspects of accessibility besides
these APIs, like providing keyboard navigation for all UI actions, and
enabling large-print and/or high-contrast themes, etc.

Perhaps I will clip and save this to a new intro FAQ for accessibility
hackers... catch me on IRC if you have questions.

best regards,

Bill

> --
> Peter Williams     peter newton cx / peterw ximian com
> 
> "Why should I have to change my name? He's the one who
> sucks!"                              -- Michael Bolton
> 
> _______________________________________________
> gnome-2-0-list mailing list
> gnome-2-0-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-2-0-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]