[Accessibility] Draft minutes Accessibility Working Group Meeting February 11, 2004

Bill Haneman Bill.Haneman at Sun.COM
Mon Feb 16 11:03:35 PST 2004

John Goldthwaite wrote:

>This needs substantial editing so let Bill have a go at it before posting.
Thanks John!

>Accessibility Working Group Meeting February 11, 2004
>Stewart Anderson
>Doug Beattie
>Sandy Gabrielli
>John Goldthwaite
>Bill Haneman
>Randy Horwitz
>Earl Johnson
>Peter Korn
>Janina Sajka
>Sharon Schnider
>Matthew Wilcox
>Janina- check on a11y.org, calls to each member, talk to Mario about having
>discussion on Shared I/O on Feb. 11 also Michael Meeks  Michael at ximian.com
>Corrections to the notes.  Bill will make corrections off line.  We’ll hold
>approval of last week’s minutes until next week.
>Janina is work on calling everyone.  No news on licensing from U. Wisconsin.
>NSF has requested a formal proposal from us for the meeting.  We will work
>on this on
>Bill- Last week, Gunnar commented that CORBA is not liked by KDE
>Janina- We need to make sure we have those comments.
>Bill- Stewart may have some comments as we’re proposing to do something
>slightly different from prior LSB efforts
>Janina- Was not able to do some of the action items due to workload at AFB.
>Talked to NSF: if we get proposal back in a month or so, we can have a
>meeting in the fall.  Doing a demonstration this afternoon for Congressmen
>on DAISY technology.  We were recapping what LSB has done vs. what we are
>looking at with AT-SPI
>Bill- DBUS shouldn’t enter into consideration.  We did mention it last week
>but it is not relevant to our discussion since it has doesn’t relate to
>AT-SPI and there is nothing on anyone’s roadmap to make it relevant.
>Janina- could be …
>Bill-  I don’t think its technically possible,
>Janina- lets recap the discussion on AT-SPI.
>Bill- Does very one have familiarity with the GNOME Accessibility
>URL-  developer.gnome.org/projects/gap
> Link in section called documents- gnome accessibility for developers
>The diagram is Figure 1 about 7 paragraphs down.
>We’re proposing to standardize on the platform layer.  This diagram is out
of date, ignore "Modified Window Manager" and "special calls".  Even so,

>Its an accurate reflection of the layers.  For backgroup, we felt that
>standardizing on applications and application behavior was more than we
>could do at beginning.  We could focus on Assistive Technology,  the
>assistive technology would work to the extent the applications were
>compliant.  There are lots of reasons that the application area is
>troublesome, but applications sh   Applications are always in their own
>process space so any standardization is going to be in the Interprocess
>Stewart -don’t you have to do both?
>Bill- need a consistent set of platform services that the AT can count on.
Can’t do it at library level, AT may not be written [in a language 
compatible] with that library. We

>need to avoid applications having to proactively having to interact with
>assistive technology.  We need them to follow standard behavior.  The
>different toolkits are sufficiently heterogeneous that we can’t count on
>this.   We’re not dealing with the application space at this time.

>Stewart- If you talking about an orb, we have a network connection between
>these pieces.
Perhaps, but CORBA and our IDL do not require that the IPC be cross-host or
require cross-network traffic. Assistive technology has been 
historically VERY non-portable.

> We’re limited in the
>AT we have in Linux, we want to design this so that the AT doesn’t have to
>deal with all the heterogeneous.  We trying to establish a standard at the
>IPC level as seen by the AT and make sure that all the applications export
>information at this level, 
sort of a 'glue layer ABI'.

> There is hope in site for this to happen.
>Having an ABI doesn’t mean it works correctly.
>Inorder for a screenreader to work on a platform it needs certain services.
>The nature of these is IPC since this a client server model.  It make sense
>to standardize on the service APIs, which we refer to as "SPIs", for
"Service Provider Interfaces".

>AT don’t have to link to C, they can do link to 
client-stubs appropriate to their own language, whose exact ABI is
dictated by the combination of the IDL and the standardization of 
"language bindings"
for the specified IPC technology. (IN our current implementations this 
technology is
CORBA, and the client binding ABIs are dictated by the CORBA standard.)
In this scenario, ATs don’t have to link to a

>specific Binary ABI.  They just link to some CORBA "stubs".  It’s the ability
>to speak CORBA protocols, that way you don’t specify
>Stewart- You’re putting more knowledge of the protocols in the application
>Bill- Not to a great extent, and it depends on the language you use.  In C, you have
"Corba Environment" structures exposed, as a way of providing exception 
handling in C; otherwise
there is very little CORBA implementation-specific detail exposed.

>Bill- point I’m making is that you don’t want to standarize at the library
>level.  Developer wants to write to an ABI,   To do ABI validation, you have
>to do standardization at the level of the IDL as expressed in CORBA.
>Stewart- it’s the ... []
>Bill- the reason for wrestling with this is that the nature of the service
>is different.  Application developers need to know that particular libraries
>are available.  You can rely on API’s being there, code works.  
However for AT the

>API’s are much more service oriented.  It may not be good to standardize on
>a binary C level.  You want to go one layer lower.  If you validate C, need
>to validate C++, Python, etc.
>The advantages- you don’t need to have a validation for all the languages
>you want to write AT in.  It means you have the potential to change your
>back end – link against a set of client stubs that were connect to an
>appropriate backend.
>In future could have...
>Stewart- you could have a set of thin wrappers.
>Bill- That’s what the IDL does for us.  The CORBA client stubs are thin wrappers around
a transport/IPC protocol.

>It’s the normative API.  The
>Stewart- isnt’ the IDL CORBA specific?
>Bill- its not,  our IDL conforms to the CORBA standard but can be used by
>You could write IDL which was compiled to some other back-end ABI.
>You have a layer you can validate against.  At the end of the day we’ll be
>validating against some binding but we don’t want to make that binding
>normative.  If 

>an IDL compiler is conformant with CORBA, we should be able to
>"share" validations across language bindings.
>The interORB protocol, there are a number of layers in CORBA that have been carefully
>specified.  We can validate, we’re going to say we have an API that we’re
>going to validate against .. going to pull implementation libraries into the
>mix or the ..
>Stewart- .. want to keep all the other language bindings in mind as well
>Bill- writing them in C is tricky, you may get better traction writing AT in
>other languages.  We’re trying to insure that AT written to our spec will
>run on any platform that’s been validated against our ABI.  Practically
>speaking, that implies a lot.  You can’t do this without a lot of
>dependencies.  You don’t want all those dependencies to be part of the
>standard.  If you leave the dependencies as implicit your okay.  … That
>doesn’t mean that every dependency of AT will be met, they tend to have
>Stewart- How about screenreaders?
>Bill- this is about making sure that the screenreader will be able to get
>information from the platform.  If its written in Python, there are 2
>dependencies- api and Python.  In practice any implementation of will have a
>lot of dependencies.  If we link at the library layer you dependent on
>having Bonobo, orbit2, orb and other specific libraries on the platform.  If
>all we’re say is that you have to standardize at the client stubs layer, we
>don’t care what the backend details are.  IDL was designed as a way to do
>API without ABI.  The IDL we use are all CORBA implementation of the IDL.
>The way CORBA works is that the IDL is compiled into a thin wrappers around
>the CORBA protocol. They are language dependent but they allow these to
>interoperate. You’ve decoupled your IPC from the languages…
>Janina- we want to go with th,  before this accessibility work began in
>GNOME, there was nothing in X.  Its radically different from the Windows
Bill- the emerging Longhorn approach is more similar to this, the older 

>platform is different.
>Janina- want the platforms to be able to deliver services needed for AT.
>Hopefully we can get enough people in the conversation to reach consensus.
>Willy- we need to more discussion on the list to elaborate.
>Janina- what will it take to get the discussion.
>John – If Bill will edit last week and this week’s minutes, we can review it
>and ask questions/
>Randy- is there some information on the GNOME site that would provide
>background so we don’t have to send so many messages?
>Bill-  …. Conformance problems with ORB, not accessibility problems.  You
>need to validate each language you write in.  AT’s are unique in that they’
>re interacting with applications written in multiple languages.  … so don’t
>need to validate against all the languages.
>Randy- is the xxx the layer between xxx in the Diagram
>Bill- all those bridges are things that take toolkit specific ABI’s and … to
>speak a … there are two sides to the interface, you could also validate
>against the application… need to be conformant…  application writer.
>Janina- … toolkit developer….
>Bill- architecture allows many different ways to reach a conformant result.
>John Goldthwaite
>Center for Assistive Technology and Environmental Access, Georgia Tech
>john.goldthwaite at catea.org
>Accessibility mailing list
>Accessibility at freestandards.org

More information about the Accessibility mailing list