[Accessibility] Accessibility Conference Thursday AM 1/27/05

john goldthwaite jgoldthwaite at yahoo.com
Wed Feb 16 14:52:33 PST 2005

Accessibility Conference January 27, Thursday AM

Peter Korn
Keith Packard- HP 
Gunnar Schmidt
Olaf Schmidt
Mark Mulkahy
George Kraft
Sandy Gabrielli
Ed Price
John Goldthwaite
Mike Paciello
Doug Beattie
French guys
Al Gilman
Larry Weiss
Will Walker
Brltty guys
Bill Haneman
Janina Sajka

Kirk Reiser
Mario Lang
Jeoff – Australia
William Acker
Willy Wilcox
Buddy – Erie PA

AT-SPI Outcomes of discussions

AT-SPI IDL is primary to our spec – foundation API
-	review IDL to make sure all should be included in

We have to validate against a ABI, we want to capture
this of AT.  If so, AT will a certain set of services
and behaviors available.  Doesn’t say SR built for one
platform will run on another but does guaranty that
the logic will not need to be check.   Assistive tech
needs to know its logic is going to be valid and stay
so.   Also would like to be sure we don’t have
re-compile – that’s where we get into API. 
Conformance requires that we contain ABI components. 

Conformance and validation requires ABI component(s)

Clients require client-binding consistency
Don’t want to have to change one binding call with
another across the whole product.  At worst they can
do a recompile and run in another environment.

Functional requirements/interoperability require
protocol standardization

	If you don’t have some have protocols that are the
same you could have bindings that look the same but
don’t interoperate.  

We wish to separate protocol from client ABIs because
there is value in allowing additional protocols in the

	Want to discuss the ABI separately from the protocol.
 Would allow us to change 		the protocol in the
future.  Thus we want to separate ABI validation from
API 		validation.  Have to make sure clients and
distributors understand what we are offering.   Need a
light weight method of changing protocols.   Should be
able to add protocols in a dot release, not wait for
2.0 or 3.0.   Need to do this within FSG procedures.  

Should begin to define acceptance criteria for new
protocols, and submission process

Should define back-compatibility and interoperability
criteria.  (don’t want to say there might be another
protocol without give idea of what backward

Acceptance criteria will need to reach up to the
bridge/server side, to ensure full functionally
compatibility with existing architecture and legacy
GAP.  Want to be sure that we can swap bridges if move
to another platform.  If change protocols, you have to
have new bridges.

Larry- Concerned about bridges, agree that they would
need to replace but don’t know how we could know what
all the bridges.
Bill-  need to have public review and interop criteria
Peter- focus on transfer protocol,  also need to think
AT side- acc
Bill- to paraphrase- We should as part of spec process
we should include language of how the spec will be

Al- another paraphrase – ideal compiler in ideal work.
 Access contract between AT, is based on having a
schema of what the information is that we need to

Bill- That is how do we extend the interfaces
Al- you’ve done a great job of summarizing.

Strawman of 1.0
Include the IDL a set of “blessed” client bindings and
existing CORBA protocol.
-	reason for blessing specific client bindings is to
aid in the new protocol acceptance criteria  -
validating useful because this is the specific
contract that the AT will work with.  We don’t know
how many API’s there will be but we want to come up
with some basic bindings you can rely on.   Will
include the CORBA protocol.   “Blessed” bindings
define what our protocol has to fit.  Despite my
concern about the Cspi is the right binding, it may be
the right one.  X  exposes the guts of Corba.  It
would best to have compatibility to Cspi rather then
to the CORBA C bindings.  Aside-  Cspi C binds don’t
have any Gnome dependency except glib.  It is already
to write AT in C without being dependent on anything
in Gnome other than glib.  The author doesn’t have to
deal with Gnome class.

Harald- Gnome things are not exposed but glib is very
Bill-  you’re saying that glib is not a trivial
dependence.  There maybe a trivial Tango

Actions for strawman
-	Review IDL for inclusion – Will, Peter, George,
Bill, Harald, couple of others.
-	Identify the problem dependencies- Harald, Olaf
-	Identify which problem dependencies might be excise-
Bill will recruit group to do this, including
Jonathan.   Need to see what dependencies are pulled
in un
e.g. libbonobo  tends to pull in all of Gnome.  Might
be able to remove,  Cspi tends to pull in everything
from both sides.  Need to go back and prune.

-	Assign resources to excise refactor code to
encapsulate or remove those dependencies.  
-	Start making contact with FSG desktop group –
Stewart will do this

- looking at changing activation method, ref-counting,
and dependency triage on Gnome ABI stability
guarantees.   Need to be sure that we don’t do
anything that breaks Gnome desktop – Jonathan, Al,  	
There are also some constraints on us from , 
Olaf- note on abi stability of KDE,  we are about to
do new release so we could break binary compatibility.
 Harald has made
Harald- we have until end of year make binary
-	we don’t have an activation ABI for 0.1, the one we
have has lots of Bonobo dependency.  Do we want to go
ahead without saying something about activation?  How
much deprecated stuff we need to leave in place not to
violate our Gnome contract?
-	What testing harnesses – tech’s should we use?  How
much do we care about dependencies of our validation
test binaries. May be better to create our own test
harness.   If we have new arch/ chip set but our test
suite hasn’t been ported to that platform, that seems
like a problem.  If our validation suite requires
libbonobo, that means they have to have a working copy
of libbonobo for their platform.   Problem but how big
a problem.  
-	Olaf- I would care about the license and not
dependency since it is test and not concerned about
shipping.  Question whether test suite would run on
imbedded devices.  Bill- test suite has be port
-	George- example lp support, S390 – if I have a
imbedded device, the developer has to be responsible
for porting the validation suite.  
-	Bill – one blind – what if the person is a open
systems group that doesn’t have the resources to
-	Al- sounds like a valid economics issues for
imbedded products, we may want to duck that question
for now.
-	Peter- more general topic- we talked yesterday about
– because of the thinking that DBUS is the way we want
to go in the future.  We should have a group to prove
the DBUS is going to be valid alternative.  Want to
have before 0.1
-	Gate
-	Peter- not a gate for the spec but we want to get it
as an action item
-	Olaf – if we have validation suites on Gnome, and we
want it on imbedded- do we have to create new
validation suite based on new principles?  No,  good.

In Keyboard,  how do we proceed with our tests.  What
format does FSG require.
Stewart- it has to be useful.
Bill- sometimes the test binary is the acceptance
tool.  Is there some format for test suites
George- gave example of Posix test
Bill- what does this group or subgroup need to
produce?  Don’t want to write test suite and find it
does not meet the needs of FSG.  Want know what I must
do, what I should do?
Stewart- FSG hires someone to be the 3rd party
certification authority.  Submit big set of journal
listing which they have automated system to parse.  We
are used to using tests as our framework.  It would be
nice to use the same tool that we are using.
Bill- someone who likes tests should take an action
with someone who knows the xxx, to write a few tests.
Doug- we spoke early on that there are some actions
that can not be tested automatically.  We need to
product script for the manual portion of the test. 
Al- The soft spot is that the DBUS fork should be a
Bill – aside- one thing for advancement of AT-spi,
independent of everything maybe we should use DBUS as
the activation.
Jonathan- good idea, t
Bill- I’ll take an action with some others to begin

George- we talked about doing activation with the X
Bill- its easy enough for discovery, but to deal with
replacement and recovery.  I want to ask if DBUS can
do that for us already.  What we have is limited to
local host and as does DBUS.
Will- the philosophy behind server model, are there
enough existing products that use the features and
Bill- before we commit ourselves we ought to see if
its what is needed.  That’s are hard question.  Any
solution is going to have holes in it.

Al- On using Atom on Xserver, I don’t want to freeze
the discussion with that.  This is a much more
universal design so we need thing about it and take
our time.
Bill- LSB is not about writing new standards but about
finding what works and making sure things are
compatible.  We want to be able to point to x at the
1.0 release.  Want to be to make changes to the API.
Peter- Is this API good enough- we’ll take this an
action item.  We know this API is rich, robust and
extensible.  What we are doing is what Apple doing
with their 10.4, it is almost a perfect subset.  It is
also what Microsoft is doing in Longhorn.  I have
reasonable confidence that as long we have a good path
for extending our spec, that we okay for 0.1  
Bill- we have 4 AT’s written to this API which cover a
wide range of modalities.  Because of screenreader, we
have two implementations for the API.  We’ve shown we
can have an alternate
Will- you can do screen readers but 
Al- Have to ask you to live in Hope,  We have stuff in
W3C that will live in the real work . There is enough
consensus to move forward.  If you --  Testimony on
the web is that screen readers don’t have data
validity with the presentation.  This model will take
us to something developer can trust.   
Jonathan-  do you know Acrobat is doing their
communications with the spi
Peter-  they are using ATK, they have some g widgets
and some proprietary widgets.  They have not made a
statement to there commitment to supporting it at the
executive level,  they have a full time engineer in
Bangalore that is working on it.  They are doing it on
the Mac and all the other platforms,
Mike- what do you mean by compelling
Will- I do believe that this is the right model,, but
what I mean is the screenreader user allows the user
to use the products and
Mike mainstream AT vendors aren’t here
Peter-  they don’t want to take risk on platform.  Now
that there are open solution, they don’t want to come
because they don’t see how they can make money versus
good open source products.

Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.

More information about the Accessibility mailing list