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

[John Goldthwaite]

This needs substantial editing so let Bill have a go at it before posting.


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
programmers.
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
Bill- Does very one have familiarity with the GNOME Accessibility
architecture?
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 day, ignore-
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
Communications.
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 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.
Bill- the software inter   historically 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. 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
AT don’t have to link to C, they can do link to    Don’t have to link to a
specific Binary ABI.  They just link to some CORBA stuff.  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
anyway.
Bill- You just have to be able to l   to CORBA

Stewart- an API that
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.  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-
Bill- That’s what the IDL does for us.  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
others.
You could write IDL
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 a compiler is conformant with CORBA, there should be able to
validate against other
The interORB, 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
many.
Stewart- screenreader
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
approach.
Bill- the emerging Longhorn approach is similar to this, the older Windows
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 cons
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