[Accessibility] Draft minutes for Accessibility Working Group
Meeting February 4, 2004
john.goldthwaite at catea.org
Wed Feb 4 12:44:29 PST 2004
Accessibility Working Group Meeting February 4, 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
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 hasnt 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 APIs 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
Bill- from the point of view of AT, its the AT layer thats 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 were 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 wouldnt be the same binary but it would be straight
forward so that the same assistive technology could run with it without
Janina whos standards are CORBA and IDL?
Bill- Common object request broker architecture (CORBA) - OMG- Object
management group. Implementations of CORBA exist under all kinds of
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 thats
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 dont
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 youre
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- were about a binary standard that can be validated.
Doug- youre saying nothing else exists?
Bill- yes, the
Peter Its worth exploring the other alternatives, e.g. DBUS
Bill- they are not rich enough, they dont 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 thats 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
Doug- pass it by
Youve got in process calls for ABI, you have binary standards for FTP, DNS,
Sockets. Were 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, its the services that are available.
Bill - At the layer were validating
Doug- weve been standardizing at the level the application are running
Bill- thats not the layer where interoperability needs to be preserved. It
s at the IPC level that we need to standardized
AT vs. application
Peter- weve got applications written via different libraries all of which
we are trying to make accessible. All cant 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. Its 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
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. ..
Bill- we dont 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 Im 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
Peter- Look at the information the desktop must provide.
Bill- we want to standardize on the information stream. Were 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. Its 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 were
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.
Center for Assistive Technology and Environmental Access, Georgia Tech
john.goldthwaite at catea.org
More information about the Accessibility