[Accessibility] Draft minutes Accessibility Working Group Meeting
February 11, 2004
john.goldthwaite at catea.org
Wed Feb 11 12:42:38 PST 2004
This needs substantial editing so let Bill have a go at it before posting.
Accessibility Working Group Meeting February 11, 2004
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. Well hold
approval of last weeks 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 were 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 shouldnt enter into consideration. We did mention it last week
but it is not relevant to our discussion since it has doesnt relate to
AT-SPI and there is nothing on anyones roadmap to make it relevant.
Janina- could be
Bill- I dont think its technically possible,
Janina- lets recap the discussion on
Bill- Does very one have familiarity with the GNOME Accessibility
Link in section called documents- gnome accessibility for developers
The diagram is Figure 1 about 7 paragraphs down.
Were 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
Stewart -dont you have to do both?
Bill- need a consistent set of platform services that the AT can count on.
Cant 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 cant count on
this. Were not dealing with the application space at this time.
Stewart- If you talking about an orb, we have a network connection between
Bill- the software inter historically non-portable. Were limited in the
AT we have in Linux, we want to design this so that the AT doesnt 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 doesnt 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 dont have to link to C, they can do link to Dont have to link to a
specific Binary ABI. They just link to some CORBA stuff. Its the ability
to speak CORBA protocols, that way you dont specify
Stewart- Youre putting more knowledge of the protocols in the application
Bill- You just have to be able to l to CORBA
Stewart- an API that
Bill- point Im making is that you dont 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- its 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 APIs being there, code works. For AT the
APIs 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 dont 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
In future could have
Bill- Thats what the IDL does for us. Its 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
You have a layer you can validate against. At the end of the day well be
validating against some binding but we dont 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, were going to say we have an API that were
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. Were trying to insure that AT written to our spec will
run on any platform thats been validated against our ABI. Practically
speaking, that implies a lot. You cant do this without a lot of
dependencies. You dont want all those dependencies to be part of the
standard. If you leave the dependencies as implicit your okay.
doesnt mean that every dependency of AT will be met, they tend to have
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 were say is that you have to standardize at the client stubs layer, we
dont 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. Youve 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 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 weeks minutes, we can review it
and ask questions/
Randy- is there some information on the GNOME site that would provide
background so we dont have to send so many messages?
. Conformance problems with ORB, not accessibility problems. You
need to validate each language you write in. ATs are unique in that they
re interacting with applications written in multiple languages.
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 ABIs and
there are two sides to the interface, you could also validate
against the application
need to be conformant
Bill- architecture allows many different ways to reach a conformant result.
Center for Assistive Technology and Environmental Access, Georgia Tech
john.goldthwaite at catea.org
More information about the Accessibility