The Linux Foundation


From The Linux Foundation

Open A11y Working Group Conference Call (18 December 2007)

NOTE: These minutes have not yet been finalized. However, an audio archive of the 18 December 2007 call, in OGG format, is available. Please use the audio recording and your own recollections to assist in finalizing these minutes -- errors, attributions, mis-attributions, clarafications and/or corrections should be posted to



  • Janina Sajka (JS/chair)
    • Stew Benedict (SB/The Linux Foundation)
    • David Bolter (DB/University of Toronto)
    • Mark Doffman (MD, Mark/Novell)
    • Calvin Gaisford (CG/Novell)
    • Bill Haneman (BH/Sun Microsystems)
    • Eitan Isaacson (EI/Accesicer)
    • Earl Johnson (EJ/Sun Microsystems)
    • George Kraft (GK4/IBM)
    • Aaron Leventhal (AL/Mozilla a11y lead for IBM)
    • Michael Meeks (MM/Codethink)
    • Gregory J. Rosmaita (GJR/scribe)
    • Rob Taylor (RT/Codethink)
    • Willie Walker (WW/Sun Microsystems/team leader for Orca)
      • regrets: Pete Brunet (PB/IBM)

For Reference

Preliminary Items

  1. continue action item on GJR re: vetting audio transcription of PB's comments
  2. Minutes from 4 December 2007 Open A11y Call approved without objection

Summary of Action Items Assigned at the 2007-12-04 Open A11y Conference Call

Meeting Minutes

Topic 1: AT-SPI, D-Bus Developements, and Implications for the Proposed Test Suite

One Sentence Introductions

JS: welcome -- many new people on call; debated whether should go around and introduce ourselves -- keep brief, so can get to substantive testing/engineering discussion

JS: chair, Open A11y working group; end-user (screen reader)

GJR: vice-chair, listmaster, webmaster for Open Accessibility working group; invited expert to W3C; end user (screen-reader)

WW: lead on Orca screen-reading project

DB: worked on team that developed GOK; working on various open source AT products

AL: Mozilla a11y for IBM

GK4: work for IBM; no longer work with a11y directly, but still an interest; want to help to ensure that what we began gets done

BH: drafted and coded most of GNOME interfaces including ATK/AT-SPI

CG: work for Novell; starting up new team to do a11y work in mono project -- especially windows forms and moonlight project and the entire GNOME structure

MD: CG tech leader of my team at Novell;

EI: developer and maintainer of Accerciser

RT: director of CodeThink -- AT-SPI to D-Bus engineering focus right now

MM: also at CodeThink

JS: custom to create audio archive of teleconferences -- password protected by apache server; is there any objection to our recording call?

none logged

JS: use passcode use to join teleconference as passcode for audio archive

Updates, Discussion & Planning

JS: can Rob or Mark brief the group of discussion on atspi list?

Mark: gone over actual practices -- different forms between ??? and D-Bus; architectural question to be resolved: what kind of ??? to D-Bus; what are the issues encountered today, what issues can we fix; ascertain how things can fit differently into different technnologies, e.g. CORBA;

JS: appreciate opportunity to have you join us on the phone

JS: burning issues or questions?

WW: like to see people's general feeling about work that has been done -- is it worth going forward with?

MM: start is great -- surprised D-Bus twice as slow; major concern in switch is take advantage of opportunity to do revalidation; want most positive benefit out of it before done -- study life-cycle

BH: some trepedation, but opportunity to change life-cycle model if convince ourselves we can satisfy the edge if not corner cases; great work -- starting to get not just qualitative comparisons, but getting more people looking seriously at D-Bus/CORBA comparission; more eyes the better; question: is this the right move? if it is, don't have any principled objections to either COBRA or D-BUS -- don't want to take performance hit if can avoid it; if decide to keep CORBA as alternative, what would we be saddling ourselves with? majority of historical baggage could be ditched, but keep CORBA in mind

MM: stripping out baggage; i'm interested in getting rid of CORBA and moving to D-Bus -- put politics and everything else aside; CodeThink task list is fantastic; GNOME, KDE, and everyone needs to decide this is right thing to do and move ahead

RT: emailed TrollTech, dissappointed they're not representated on call

JS: is Harald Fernangle your contact? i've been pinging him; need TrollTech and KDE to be part of discussion

RT: no, not Harald -- the guy currently in charge is -- looking for it... [posted to IRC} Jan-Arve Saether

DB: let's try and get him into the discussion

RT: know their D-Bus guy very well

WW: good thing is that we are reaching out as a community; doing work in open and in public eye -- question for Michael about Microsoft's new architecture -- needs to be discussed

RT: need to move towards convergence -- immediate thing that jumps to mind is lifecycle -- ATK harmonization, feature equivalent and bridgeable

WW: discovered working with Orca API that a lot of stuff can be done under the covers --

EI: not sure 100% -- trying to read up lifecycle thread on list; ran into problem with caching early on -- need caching, but what if lifecycle short and document goes away before cached; diff shcemes may be different over the wire, but should be same for caching

MM: nice caching things in UIA -- good thing to add/map to ATK

WW: moving in that direction; in terms of lifecycle, thing most like to delete is explicit reference counting by clients

MM: yes,

GK4: timely notification when object gone or out of scope would probably solve EI's problem

EI: correct

GK4: shorter lifecycle that way; IBM interested in what others think in terms of performance penalties, how big a performance hit can we live with moving to new technology? as corallary, will implementing collections API validate our concerns? would htat make it a moot question?

WW: performance a very important issue -- timely feedback and input/output; when using FireFox to render documents with large amount of content, want to jump to elementX want to list all elementX -- not sure how collections API could help

DB: the "walking the accessibility tree" delay is in the order of seconds -- hard on user; 10 seconds bad, 20 seconds worse

BH: really expensive operations are those with schemes from collection; maybe the answer to WW's point is that would benefit all through collection -- if reduce granularity of API -- give 1 notification for state change or change in tool kit set;

GK4: let's look at 2x and see where we are -- sometimes D-Bus faster, sometimes slower -- what is overall impact on GOK, Orca, etc. -- want to ascertain net impact

Mark: net impact -- D-Bus faster in passing references; overall, D-Bus going to take a hit in order of 2 to 3 times; not sure anything D-Bus doing that is more complex than COBRA, don't know why slower -- D-Bus optimization should go on list

BH: probably get half of hit back

GK4: if want object references as flexible as COBRA ones, would lose D-Bus advantage

??: not sure how much needed -- smaller string than in COBRA

GK4: can short object references be cracked? security issue?

??: object references in D-Bus aren't hidden; in COBRA opaque; no concept of hiding reference in D-Bus

WW: think security on different layer; need priviledges to do so

GK4: network transparency only important for application instances and embedded resources - not for things at root of component -- complication in AT-SPI object can be re-parented - can't use single path to object as algorithm

??: wouldn't use object paths --

object path for D-Bus

RT: like to see an outline of the new world -- look at the proposed design

MM: absolutely right -- need to look at object references; D-Bus

RT: may be a start in questioning how works

MM: depends upon broker for events

RT: like to use D-Bus; fits quite well -- signal synchronization (one-way messages) - app registered which signals received

RT: next step is float a proposal -- lifecycle and navigation

MM: main thing at moment is lifecycle and flow control question -- very broad decisions to make; not sure what the right answer is yet

JS: who will create proposal for path for everyone to discuss?

RT: CodeThink (RT and MM)

JS: make every effort to make KDE aware of what is going on -- if anyone has alternate proposal, should address now; who other than KDE should be approached?

SB: mobile devices and mobile platforms -- D-Bus requirements for those platforms

??: need to bring in and hear their concerns

WW: anyone working for ubuntu on call? -- would be good to include them -- been active in area in last year or so

JS: not sure any ubuntu people are subscribed to open a11y lists

WW: will send JS contact info; another issue is java platform -- need path for that too

BH: java to D-Bus mapping, but java internal to AT-SPI is transparent; methods implemented 90% of code doesn't know dealing with CORBA -- no IDL code generators for D-Bus

RT: introduce components of that technology into D-Bus --

WW: help with bindings (python, etc.) transparency

??: IDL normative versus XML normative -- one is like another provided XML not bloated; XML has benefits for describing interface in lang and toolkit neutral way; as neutral if not more than CORBA; don't want to move to less concise IDL -- one good thing about CORBA is conciseness

??: need to sync with IAccessible2

JS: considered standardizing IDL as neutral

??: that was our position -- just want to be sure that XML as nice as IDL

MM: implementation detail that should be hidden to greatest extent we can

??: no problem with that -- CORBA IDL not precisely neutral

??: XML versus IDL -- ease of reading and writing; XML ease of transformation to document format

??: oxygen can parse IDL -- alot of inline documentation in IDL

??: oxygen doesn't handle IDL at lower level of granularity -- could use XSLT to transform into "pretty" pages or docbook

??: surprised -- oxygen plus IDL

??: really don't like

??: no advantage one way or another

GK4: machine parseable format that is easy to read?

MM: yes, machine parseable, easy to read

??: IDL has to be machine parseable

MM: true, depends upon what parses it

??: can live with machine parseable as long as can still read interface definitions

??: if go to XML has to be something readable, not a hyper-customized dialect; working on examples -- will post to emailing list

MM: implementation details -- use D-Bus can lay stuff ontop of raw interface to deal with caching issues and document IDL in detail

BH: nice not to be tied into single mechanism

MM: UIA gets this right -- AT-SPI black box

??: depends upon how UIA works -- defining an interface or way for apps to talk to one another?

??: shouldn't be writing in D-Bus XML

MM: but not standardized --

??: XML and XML-derived languages can create new bindings to write interpreter/compiler for interface -- theoretically great strangth of COBRA -- should retain so can point people in future to an IDL

MM: java doesn't do that; phython wraps COBRA; we've wrapped in C

??: java had pre-existing a11y API -- part of building java is running java IDL compiler

MM: bridge piece needs to be easier

??: can swap out glue, but when add new language, going to have to add new bindings

??: relatively straightforward -- have to be library applying to

MM: sharing is the pain

JS: what is elegant is a protocol that, in theory, has IDL compilers for target languages to create language-appropriate bindings, but at end, diff languages would perceive as objects --

??: pycorba nice for this -- model can be extended for future languages -- hope for D-Bus, right?

JS: want a standardized interface description, just not sure of details

EI?: thought didn't want standardized until get to AT level

???: the "I" in HCI

JS: need to return to this issue -- can we briefly speak about implications of testing in LSB moving towards D-Bus -- does it change anything substantively? libatk in LSB -- working on LSB perfomance tests to ensure AT will receive useable info to transmit to user; ATK/AT-SPI layer -- does that change anything?

GK4: not sure -- pyatspi?

??: dozen tests of ATK in C -- russian academy of science has over 200 test cases for ATK -- don't know if just calling API that exists or what

??: what method are they using?

??: have to investigate -- think a lot of COBRA code

MM: no conceptual difficulty if atspi-based -- if going from COBRA to D-Bus, may be a good test to ascertain if D-Bus successful

GK4: agree

JS: just past the hour -- thank everyone for participation -- any last thoughts?

New Business

  • availability of participants for calls for remainder of December 2007 and beginning of January 2008? extremely limited
    • the next Open A11y Workgroup conference call will be held on 8 January 2008

Identify Topics for the 8 January 2008 Open A11y Teleconference

CG: are you going to go through topics for next meeting? could present UIA work and our intentions vis a vis Open A11y -- go through what we are planning

JS: next vcall 8 January 2008 --

CG: can we address some issues with IA2 as well at that time?

JS: yes -- Pete Brunet of IBM, and chair of IAccessible2 workgroup at Open A11y, will resume his usual active participation in January 2008

RESOLVED: The next meeting of the Open A11y Working Group will be held on 8 January 2008

JS: if need to add additional calls can schedule subteams to meet at separate times -- whatever moves agenda forward

WW: bursting to say -- big thank you to the Mozilla Foundation for their funding and especially Rob and Mark for their professionalism and their willingness to share so openly

Wrap Up

Summary of New Action Items

Summary of Continued Action Items

Summary of Resolutions

  • The next meeting of the Open A11y Working Group will be held on 8 January 2008.

[Article] [Discussion] [View source] [History]