[Accessibility] Draft minutes for Accessibility Working Group Meeting February 4, 2004

[John Goldthwaite]

Accessibility Working Group Meeting February 4, 2004

Doug Beattie
John Goldthwaite
Bill Haneman
Peter Korn
Janina Sajka
Gunnar Schmidt
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

Last weeks minutes approved as revised via email.

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 the list this week and try to get it back to NSF next week.  This
is good for two reasons. We need to have a meeting this year and we need the
recognition that comes from having the funding from an agency like the NSF.
The meeting will help us get broader participation.  Janina will post the
letter and past documents on the website so we can discuss this.
Janina hasn’t talked to Mario about meeting next week. Mario knows all the
people and is capable to get into the code.
Bill - the support for Braille-tty is an open issue.
Janina-  Dave Melke co-maintainer of Braille-tty should be involved.

Bill- Proposal- take AT_SPI subset.  It is now a set of API’s in Gnome.
There is a layer (IDL definition interface definition language) that is
CORBA defined that would be a candidate for a standard.  One implementation
is fully free and has no dependencies.  The other is JAVA 
.
Peter- Open
Bill- from the point of view of AT, it’s the AT layer that’s the most
important to standardize.  IDL is a generic method for describing an
interface without resorting to a programming language.  The is a particular
one CORBA that is used for   There is existing software that can parse IDL
and turn it into code.

Janina- is i18n using IDL as a mechanism for internationalization?
Doug- No, we can talk to them about it.  They also meet on Wednesday 2 hours
before our meeting

Bill- IDL itself does not have any direct international influence.  You have
to think about which parameters in the interface need to be localized.  It
would make sense for the international groups to have a look at any
standards.   Likewise, we should be looking at what they are doing.
Janina- this was mentioned at the FSG meeting.
Bill – we’re talking about an interface that is seen by the AT and is
exported by the OS.  The best candidate is a layer that is defined in IDL.
This means it is not specific to a programming language and is leveraging
the CORBA standards.  It is also a good candidate for migration to other
implementations.  We could put it forward as a binary standard but could
also allow other alternate non-binary standards.  If we needed to do
something for embedded Linux which does have all the things that are in the
desktop version.  It wouldn’t be the same binary but it would be straight
forward so that the same assistive technology could run with it without
modification.
Janina – who’s standards are CORBA and IDL?
Bill- Common object request broker architecture (CORBA) - OMG- Object
management group.  Implementations of CORBA exist under all kinds of
licenses.
This layer has been implemented in C for the Gnome project and in Java as
part of the bridge in the AT-SPI project.

Question whether we want to do an API or ABI

Gunnar- KDE will use a bridge from the Q-accessibility framework, so that’s
no problem.  The only problem is that CORBA is not liked by KDE programmers.
Using CORBA for inter-process communication for KDE 

Bill- we need an interface that is not specific to a platform.  I don’t
think we have another good candidate.  From the point of applications, the
programmers would not have any direct contact with this.  Developers of AT
would be using an API based on CORBA.  Depending on the language you’re
programming in, CORBA maybe obvious or pretty well hidden.  Its messy in C,
but better in C++.  For AT you need rich inter-process communications.
Gunnar is making a good point, if we have a binary standard, it will be
based on CORBA.
Doug- we’re about a binary standard that can be validated.
Bill- there 

Doug- you’re saying nothing else exists?
Bill- yes, the
Peter – Its worth exploring the other alternatives, e.g. DBUS
Bill- they are not rich enough, they don’t provide enough facilities for
inter-process communication.  There is not an object oriented DBUS

Gunnar- currently KDE uses DCOP.  It is planned to use DBUS in the future.
Peter- is it anticipated that DBUS will be enriched for IPC?
Bill- DCOP is limited, they are thinking of creating MCOP which would allow
richer object oriented processes.  
. None of these other products support
inheritance, overriding of behaviors, 

Doug- with LSB 2.0 a major portion is the addition of C++
Bill- that may argue more for CORBA since there is a good interface to CORBA
in C++.  But that’s a language we need a ..
The only other possibility is JAVA-RBI.  CORBA allows Java, Python, C++ and
other libraries to communicate seamlessly with each other.
You are saying that particular CORBA services are available to the language
and libraries.
Doug- pass it by 

You’ve got in process calls for ABI, you have binary standards for FTP, DNS,
Sockets. We’re proposing an ABI standard that has all the features of API
accessible via IPC.
>From the point of view of the application, the fact that its based on CORBA
is not important, it’s the services that are available.

Matthew-
Bill - At the layer we’re validating
Doug- we’ve been standardizing at the level the application are running
Bill- that’s not the layer where interoperability needs to be preserved.  It
’s at the IPC level that we need to standardized

 AT vs. application 
 we’re
Peter- we’ve got applications written via different libraries all of which
we are trying to make accessible.  All can’t link to the same 
.  What is
being proposed for standardizing is the IPC.  Whatever library is used, it
needs to use the lower level of IPC to talk to the AT.   It’s far richer
that things like HPG
.
Janina- we also have to look at the SPI 
. Running out of time for today.
We need to get Michael in next week.  Are there other people from KDE that
need to discuss this?   If DBUS is not ready to provide this kind of
behavior

Peter- there are two ways of viewing IDL – object-methods interface and
generator of code via parser.
Matthew- will talk to some of folks and try to get them on the next call.
Peter- focus on the information that has to be exposed for the application
to be accessible.  This is a large stack.  First think about information
that every application needs to expose to support accessibility. ..
Parent-child relationships 

Bill- we don’t want to get into that next.  focus on the AT first.  This a
description of the types of services
 We want to go toward an ABI, there is
the API, there is an ABI that can be tested against.  There could be other
ABI implementations for the API 
.
what I’m taking about is – from the point of view of the AT.  If you start
talking about the applications, it can be confusing.  We need to look at one
side first.
Peter- Look at the information the desktop must provide.
Bill- we want to standardize on the information stream.  We’re not working
on certifying applications for their compliance.
Janina- we need to have this conversation with enough people to have the
buy-in for the standards.
Peter- you have to be able to validate and verify.  It’s useful to
distinguish between the API and ABI.  Often standards level some items
undefined. You validate against the 

Bill- we provide – if I write an assistive technology that runs on a
conforming platform, it should be able to run on others.  What we’re
certifying is that the desktop has the
The advantage of doing the standardization at the IPC level is that all the
languages and libraries can use it.


John Goldthwaite
Center for Assistive Technology and Environmental Access, Georgia Tech
john.goldthwaite at catea.org