From The Linux Foundation
Revision as of 20:23, 6 May 2008 by Oedipus (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Open A11y Working Group Conference Call (29 April 2008)


  • Janina Sajka (JS/chair)
    • Pete Brunet, IBM (PB)
    • Mark Doffman, CodeThink (MG)
    • Calvin Gainsford, Novell (CG)
    • Mike Gorse, Novell (MG)
    • Peter Korn, Sun Microsystems (PK)
    • Gregory J. Rosmaita (GJR/scribe)
    • Gunnar Schmi-DT, KDE Accessibility (GS)
    • Rob Taylor, CodeThink (RT)
    • Andrew Updegrove, The Linux Foundation (AU)
    • Willie Walker, Sun Microsystems (WW)
      • regrets: Karen Copenhaver (KC), Steve Lee (SL)

For Reference

Preliminary Items

Approval of Past Minutes


Meeting Minutes

Topic 1: ATK on D-Bus Update

For Reference:

Discussion Points:

  • What applications need to be rewritten that will not be covered by CodeThink, e.g.:
    • gnome-speech, py-atspi, and others
      • How do we move these in parallel with the port to D-Bus?
  • How to test on small devices?
  • How can we use this work to expand the community of accessibility developers in Gnome, KDE, Linux, etc.?

JS: how to make successful port

RT: Mark and i have been working; Mike has jump on it -- been doing work over D-Bus for over a month

MG: started mid-March 2008

RT: perhaps MG can start by telling us

MG: things to be done: work needs to be done on programs exposing info to send info to AT; concentrating on writing methods that would allow AT to query application, then send over wire using D-Bus; been talking with MarkD about a spec to move over a lot of other stuff; a lot of communication necessary for performance's sake -- trying to figure out how to cache information, then send groups of information (for example, all the elements and attributes of a TABLE) to AT for potential use; have draft of specification and working on writing code; other parts that need doing: trying to work with ATK-Bridge and registry daemon work that needs to be done (read cache and implement)

MD: MG has an initial draft of moving AT-SPI to D-Bus; fairly direct transfer from old to new -- caching the important gain so far; a lot further than thought we'd be

RT: accessibleObject -- will change; accessibleInterfaces will stay mostly the same; accessibleObject will be replaced by tree; by changing so AT uses a local view of the tree (could be cached / downloaded locally)

WW: going to be very important; mouseTweaks, GOK (GNOME On-Screen Keyboard) and Dasher -- what can we do to get that in place so will be allowed in GNOME?

RT: actual API -- what makes sense for them; from Nokia view, main interest in pySPI using DogTail; don't know if will get Nokia to do AT-SPI work, might end up totally in python -- same for UIA?

MG: eventually need C-sharp bindings -- there are D-Bus bindings for C-sharp

RT: D-Bus in C-Sharp yields good performance

CG: UIA bindings, yes, but looking into writing C bindings

RT: AT-SPI compatible with Cspy or need to provide a library

RT: at least a small library talking with the tree and performing caching

MD: wouldn't take too long to try

RT: get from library or recompile -- still considering

WW: would prefer to throw CSpy out and have AT directly communicate with accessibility API

MG: biggest concern -- don't want to do work that is going to end up incompatible with GNOME

GJR: are you in touch with David Bolter at the University of Toronto -- maintainer of GOK?

RT: yes

WW: although there are owners listed for GOK and Dasher, no one really maintaining GOK or Dasher now -- busy doing other things

RT: there will come a point when technology more or lest in place, have to have people check out if everything still works -- Orca, Dasher, GOK

RT: take up cause of GOK and Dasher at point when everything relatively stable and alpha testing

JS: useful to have a sense of where issues lie; identify people to do tests, acquire funds; number 1 concern is that we don't loose any functionality; second level - pieces that are missing (remote console access, etc.); Mark Mulchay (sp?) wants to work on small and embedded devices such as his icon

RT: gives people a lot more options in mobile space

JS: still blows my mind that by 2012 50% of mobile devices will be linux

RT: get ready for bluetooth accessibility devices

JS: GNOME Speech one of our primary concerns

WW: CORBA-based right now -- some things being discussed; other alternatives being explored; it's a big hairball in our throat

RT: GNOME Speech provides CORBA API to daemon

WW: service desktop thing can use -- perhaps a separate conversation

RT: open desktop d-bus

WW: problem: everyone knows how to do speech, but everyone does it idiosyncratically

JS: what does accessibility mean in audio environment requirements document -- have started something similar in the past; if get everyone talking to one another, perhaps through the [[Accessibility/IO|I/O SIG to speak about the audio environment; thought i had heard good news about pulse audio

WW: even pulse audio a cause of polarization [sigh]

MG: different issue from how AT sends stuff to synthesizer

JS: problem: have D-Bus migration ahead -- need way to happen, and probably not CORBA way

WW: keep step-by-step now

JS: RT, MD, or MG -- is pseudo and remote access on your radar?

RT: pseudo an interesting case; package kit work -- apps running in groups should just work

MD: for remote access need to work on SSH forwarding the busses

[scribe's note: Andy Updegrove joins]

JS: conversation to be continued -- so delighted that it is happening

RT: i'm excited about it too -- any questions, just send an email

WW: thanks for sticking with it, Rob!

Topic 2: Intellectual Property Rights Policies

Special Guests: Andy Upgrove and Karen Copenhaver

For Reference:

JS: welcome to Andy Updegrove, attorney for LF, and thanks for willingness to help us vis a vis AIA and Microsoft. As people will recall, we would like to work with AIA, but have several concerns from several directions; working to get resolved -- to help us get a better sense, asked Andy and Karen to join us

JS: We've had conversations on this call with Rob Sinclair: 2 issues: 1) how governance works in AIA -- consensus driven, executive decisions; 2) licensing issues that arose from reviewing the Community Promise -- concern about "assert" clause; FAQ about the UI Automation Community Promise on MSDN site ambiguous; how to best take advantage of Andy's ability to be with us?

PB: one other question: There are 2 methods Microsoft has requested for addition to IAccessible2. Theseare to support MSAA childIDs (simple elements) and would be equivalent to the same methods in UIA Express. The UIA Community Promise Specification states that a certain minimal set of the UIA (or UIA Express) must be implemented. Although the Microsoft accessibility technology team has given us approval to implement those two methods does the fact that IA2 would only implement two of the UIA Express methods be a violation of the UIA Community Promise?

PK: curious if you could give us LF's role and perspective

AU: offering to listen to make sure we know what we are talking about; today probably listen more than speak; need to get up to speed before can answer questions; LF hosting and very happy to do so; happy to act as a legal resource as we would for any other LF hosted activity; will be talking with Jim Zemlin, so can carry questions and info to him; neither Karen or I are patent attorneys -- can give lots of advice on lots of issues

AU: have told Rob Sinclair that Microsoft has frequently amended OSP -- no change record at MSDN -- blogged about it, had an effect upon it, but didn't log change;

AU: OSP OpenXML promise -- things not problematic at time of drafting, can become problematic later; there is a line in the OSP that refers to applying only to aspects of specification that are "supplied in sufficient detail and not [scribe missed word] outside" -- understand including normative dependencies on external modules, nothing in OSP to cover this; what Microsoft is pointing to on web cannot be relied upon; need to read entire OSP

JS: in email conversation, UIAutomation Promise appeared to differ in some essentials from OSP;

AU: will cross-compare and report back

JS: relating to the assertion/requirement only applies when certain minimum portion of spec -- differs fundamentally from what is usually considered an open source license -- amount taken (1 line of code or a million lines of code) doesn't matter or have ramifications; also perceive in minimum standard, suggestion that someone going to take responsibility for conformance -- who?

AU: some observations: collision between open standards and open source -- to the extent that open standards and open source are in violent conflict -- ethos of open source you can change anything; on other hand, what makes standard work is agreeing on a standard means of achieving end so that interoperability ensured; conjoined with that is IPR concern regards standards: try to balance rights of patent owners with common good which can get out of standard; one means is for a patent obligation in a standard to apply only to an entire application; patent commitment usually refers to "REQUIRED" elements (RC2119 Required) -- implementing only part may not result in interoperability, so there needs to be a baseline in a standard

PK: hit nail on head: issue at cross-roads of open standards and open source -- don't see requirement that needs to be done in way is being done; makes sense in context of what UIA may be attempting to achieve (implementations that sustain necessary interoperability) and the fact that trying to stretch standard (UIA NOT an open standard) for some degree of interoperability for cross-platform applications -- diff standards on diff platforms at lowest possible cost (in resources of all kind); AT-SPI open source; UIA on Vista and some Vista apps and ATs (proprietary); Apple has own proprietary app; cross-platform apps using these 3 different expressions of accessibility API -- FireFox3 works with Orca, VoiceOver, and JAWS/Window-Eyes/etc. -- need additional clauses from microsoft that go beyond approach of stating you can do whatever is necessary, need to recognize and allow certain things to occur

AU: business argument strongest:

PK: discomfort with language of microsoft promises -- have expressed directly to Rob Sinclair, in open fora and whenever have had the opportunity

AU: flexible enough?

PK: not convincing to me

JS: no response to specifics email to Rob Sinclair yet.

CG: Novell are implementing UIA -- have outstanding issue -- want to license our code using MIT X11 license, which is quite open -- still waiting for response; UIA specification is run by AIA, which is steered by microsoft and hand-picked people -- was vote to open up steering committee -- unanimously agreed to open 2 new positions and will have elections within a month

JS: thank you CG; challenge on both sides of table

CG: completely foreign area for Microsoft; seem to be open when speak with them -- interested in solving problems -- at least team that is leading AIA participation -- company side, cannot talk for

PK: have a lot of appreciation and respect for work and integrity of a11y workers at Microsoft; at 2 occasions prior to this, cross-platform has meant "do as we do lock, stock and barrel, or don't do it at all" -- evolution in AIA welcome, but cautiously optimistic and somewhat suspicious -- need Microsoft to "show me" like a missourian; don't want limits on what we can do how we do it or our goals just to have interoperability with Microsoft

JS: do want to protect basis of principles -- open standards and open source

JS: given how far AIA has to go to meet us, might take more than one try; coming to a head because PeteB and IAccessible2 group very close to being done; question about moving to ISO status -- don't want to loose what ISO would give us, but holding up for a while while we negotiate we can achieve comfort

AU: maybe too late -- may need to work out elsewhere in the process as with XML precedent

PK: effort begun with a handful of people with express intention of creating open standard; have worked in open, have achieved level of programmatic access that is envy of other platforms; approach successfully duplicated in apple through VoiceOver; being duplicated by Microsoft in UIAutomation, and now sounds as if being asked to slow down momentum to achieve interoperability, which is a good goal, but need to carefully analyze cost benefit analysis -- to what extent does being interoperable with UIAutomation when have interoperability for IA2, which is supported far more broadly than UIA --

JS: good point to end upon -- continue conversation next week for additional clarity

AU: caution that this is the type of topic one can talk about ad nauseum

JS: PeteB is weeks away from forwarding IA2 1.0 to us and then to the LF board, so have an upcoming benchmark deadline for discussion of issues; need to see momentum coming to us from AIA

CG: plan on following up on a lot of these issues; will report back at subsequent meeting; will point to meeting minutes

JS: looking to see if possibility to get to "yes" for the greater benefit

PK: explicitly asked to slow down ISO process? who in what forum?

JS: Rob Sinclair in private email to me and in person after CSUN presentation;

PK: can you share this email?

JS: will forward Rob Sinclair's email to the list with my response

AU: OSP may be immovable object -- significance and ramifications -- can try to ascertain if any changes are pending to ascertain if any flexibility

JS: UIA promise differed from XML OSP

AU: want to go farther than OSP

Some of Andy Updegrove's Blog Posts on the Topic: > standards blog > February 22 2005

JS: procedurally come back to discuss next week or two?

CG: can do next week

PK: can do next week

AU: Karen and i had wrong passcode -- can make next tuesday at 2 or 2:30

JS: 2pm probably best

Topic 3: SIG Updates (conditional)

Topic 4: Topic 4: Website Update (conditional)

Open Questions:

New Business

Identify Topics for the 6 May 2008 Teleconference

  • further discuss IPR issues in preparation for a joint meeting with Accessibility Interoperability Alliance (AIA)

Wrap Up