From The Linux Foundation
Revision as of 21:41, 16 June 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 (22 January 2008)


  • Janina Sajka (JS/chair)
    • Stew Benedict (SB)
    • Pete Brunet (PB)
    • Mick Curran (MC)
    • Mark Doffman (MD)
    • Calvin Gainsford (CG)
    • Andres Gonzalez (AG)
    • Bill Haneman (BH)
    • Peter Korn (PK)
    • Michael Meeks (MM)
    • Gregory J. Rosmaita (GJR/scribe)
    • Robert Taylor (RT)
    • Gunnar Schmidt (GS)
    • Olaf Schmidt (OS)
    • Willie Walker (WW)
      • regrets: none yet logged

For Reference

Preliminary Items

Approval of Past Minutes

Announcements & News

JS: The Linux Foundation will be holding its second Collaboration Summit from April 8 through 10, 2008, at IBM in Austin, which is home-base for some of you; I have been asked to put together an accessibility track there; presents us with a very good opportunity to move issues forward;

Meeting Minutes

Topic 1: Novell's Linux Initiative (Calvin Gainsford)

For Reference:

JS: our first topic is to have Calvin Gainsford introduce Novell's initiative with linux and bringing accessibility to mono

CG: accessibility on mono is on linux -- all work directly on linux platform

CG: Michael Meeks (MM) and i are part of team working with microsoft on UIA -- so i want to start with "what is UIA?" and "how does it effect accessibility in linux?"

CG: 2 benefits: 1) novell has technology that developed -- mono .NET runtime on linux (written and executed on linux); support windows forms UI Class library -- can be executed on linux as well, but NO accessibility for any of the applications; also have implementation of microsoft's Silverlight called Moonlight -- no native accessibility in either; work on accessibility as use these frameworks will make them more accessible; another benefit is to provide accessibility interoperably with ATs on the linux platform; want linux-based ATs to be able to interact with these applications; ensuring interoperability between existing technologies and what we are developing is a major aim; never had specific accessibility team at Novell -- we will have a dedicated team, including testing and packaging to help move all data we collect to Open A11y

CG: next i'd like to address how we plan on implementing accessibility in WindowsForms and Moonlight -- applications written in .NET in Windows will take advantage of UIA (part of .NET for 3.5) -- want to run on linux and be accessible; implementing new toolkit to UIA specification and allow to tie in through ATK/AT-SPI level so ATs can communicate with it

CG: finally gotten through backlog of email; hard to find engineers to work on accessibility projects; focused so far on getting team together; as come onto team, will get involved in Open A11y -- will join lists, contribute to telecons and specifications

CG: will post regularly to keep Open A11y up to date -- hopefully more detail will be available shortly

CG: questions?

JS: please forward job descriptions to the Open A11y lists -- we may be able to assist in finding engineers; thrilled that you are participating in this open standards project

MM: first free software application technology on Linux will be Moonlight (a port of microsoft's Silverlight); and it will be accessible from day 1 -- even if Novell doesn't end up using it, we will encourage Adobe and others to do the "right thing" and adopt it

MM: Accessibility Interoperability Alliance (AIA) -- want to integrate some of what is going on in Open A11y into AIA work to ensure interoperability is not impeded by spurious intellectual property and patent concerns

BH: what is current state of accessibility for UIA and .NET apps on windows in terms of user experience and what is expected in the next 12 months -- estimated speed of change?

WindowCatcher is a FOSS (BSD) example UIA AT created as part of an Ace Centre project to investigate UIA. It's available on
The WindowCatcher project report provides a lot of detail too
Steve Lee, post to (2008-01-23)

MM: don't know if there is any "official" answer; bridges between MSAA and UIA and IA2;

BH: trying to establish if we'd be in situation of playing catch-up or will apps be more accessible on mono than Win32?

MM: getting apps fully functional on Linux our goal

PK: first, thanks to Calvin and Michael -- first question: how large will team be?

CG: including myself, 8 engineers and a handful of testers (5 or 6 building and running tests)

PK: 13 to 14 people? great

PK: another question: been a lot of confusion about what this work is in relation to UIA and Linux; easy to get impression from press releases that this is about making UIA a new accessibility standard in the linux world -- can you clarify whether it is mono/silverlight/winforms app would only expose ATK or seeking development of AT that will split UIA between themselves and apps?

CG: 2 sides: client interface and provider interface (equivalent of ATK) -- will map provider side to ATK and client side to AT-SPI; may not map exactly, but attempting to; no benefit to bypass existing structures because want existing ATs to work with mono applications and mono framework -- want to allow interaction with native linux applications

MM: purely a managed DOM API

PK: just to be clear -- you aren't anticipating exposing UIA variant to Unix/Linux world?

MM: possible but only in a managed DOM environment; don't envision anyone building something like Orca with .NET platform

PK: something we noticed in Java is that we have a java accessibility API that runs on all platforms; so the question has been raised, why not a java AT? the answer, of course, is that such a solution would not provide access to the rest of the world that isn't java-based

MM: if bridge well enough and merge UIA and ATK -- five years in the future, it may be possible to write AT that works on Windows and Linux

PK: curious if you mean linux, GNOME, or Unix when speak about novell's work with mono?

MM: should run on GNU/Solaris as well --

PK: don't yet have time line or schedule -- will it be forthcoming?

CG: as soon as i can pull it altogether

PK: finally, I'm curious about the extent you think the work will happen in AIA and what will be conducted here with Open A11y -- Novell only Unix player in AIA to my knowledge

CG: was just on AIA conference call 2 hours ago -- UIA spec being developed and managed in AIA -- work with UIAutomation will be done within AIA, but implementation and bridging connecting to other technologies will be done in Open A11y; want team to be open, so answer is we will be in both, depending upon what we are working on -- all will be done in open and be open source

MM: liaison role between AIA and Open A11y by CalvinG and myself

JS: may need to take an hour of Open A11y conference call time to speak with AIA directly to clear the air and ensure that all work is in sync

AG: does your mono runtime run under windows as well as linux?

MM: yes

AG: what is windows approach -- UIA to MSAA mapping or are you considering IA2 as well?

CG: focus now on linux -- that's where we want to solve the problem; if people want to work on windows port of mono accessibility, that can happen

MM: implementation of WinForms should work with UIA accessibility stack, so basis for windows accessibility already there

PB: so mono is an organic effort, not a port from windows?

CG/MM: correct

PB: does mono have any native accessibility support?

CG: UIA work being done on integrating accessibility into mono

PB: what is state of mono then?

CG: implemented 2.0

PB: once get WinForms implemented in mono, what then?

CG: if one writes a WinForms application on linux, nothing is enabled at all -- if run standard WinForms application, it will be provided;

PB: how much UIA implementation in WinForms?

MM: mostly MSAA to UIA -- will have better, cleaner, faster access

PB: already MSAA ATs on Windows and there is an ATK AT, Orca, so there is more support in that respect

PB: Calvin, have you started analysis of UIA?

CG: will reply to PB's recent post on the topic on list

MM: preliminary analysis: "quite doable"

PB: plan on building UIA to ATK mapping, right?

CG: yes

PB: consider leaving open for IA2, too -- bridge to windows might be portable

WW: no significant ATs are supporting UIA in development work on Windows, due to no significant (at least in economic terms) Windows application supports UIA; AT developers responsive rather than proactive -- no reason for them to make an investment in a new technology unless there is a user demand or need

CG: think UIA already in Silverlight

MM: not finalized and ready to ship

WW: until its on the ground; many commercial AT vendors state up front that their product will work on Vista, but recommend using WinXP

CG: not our intention to get implementors to switch to UIA -- by implementing this, Orca will be able to interact with WinForms; more than just specification -- will bring more accessibility to the desktop

MM: our hearts are not invested in UIA or anything else, but in getting free software stack improved and accessible

PB: can you help us understand why mono and moonlight on linux

MM: Miguel had a very good blog post on why mono and why moonlight -- at some level, people are going to use the microsoft standards, so improving linux support is important; microsoft itself is shipping software for linux

JS: on that encouraging note, let's turn our attention to today's second main topic

Topic 2: Issues from IAccessible2 to resolve with AT-SPI

For Reference:

JS: one of Open Accessibility's goals is to promote greater interoperability between IA2 and AT-SPI -- on last week's ODF call an issue came up that i am tasked with bringing to group, but today, we're concentrating on some issues that were identified late last year

PB: a couple of issues came up back in October -- one raised by Mick Curran, who is on the call -- about documents, tables and objects used in those -- trying to understand if have right functionality for ATs to manage

PB: second from ODF: revision information in ODF documents -- how to provide/expose that info?

PB: third, with BH's retirement and the shifting of personnel at IBM out of accessibility the state of the AT-SPI documentation at has become an open question -- Catherine Laws did a lot of work on Accessible Document Interfaces (ADoc) -- and a lot of that work syncs with Collections issues

PB: analyzing ADocs today -- do we need to form a team to finish/complete ADoc work? -- all of Open A11y could benefit from ADoc work

GJR: please note the new wiki pages i created for this purpose:

PB: any thoughts on putting together a team to do this work?

JS: important that have ATK/AT-SPI implementors as well as IA2 developers on team

PK: would add that have at least 1 person familiar with OpenOffice implementation; should also have a representative of a screen-reader developers on sub-team

PK: is this the right time to be putting this on our plate?

PB: no need for fire-drill for this -- my plate very full too -- can Sun identify 2 people (an AT person like WillieW and an OpenOffice person?)

BH: one thing that i remember from original conversations, is true that ADoc and Collections looking at same problem space, but never fully merged both notions; from ATK/AT-SPI perspective, felt Collection interface plus Accessible Document Interface could solve same problems; same goal; if i can be of any use, please tell me -- perhaps a face2face for a few days would be best way to kick off and hammer out issues in one extended session

JS: may have some funding support for Linux Foundation summit in April

BH: i will do what i can to make myself available

PB: great! -- not a lot has happened since you retired!

MD: need an ADoc interface (reference counting changes, point of interest in document, area surrounding point of interest

BH: reference count in AT-SPI document -- if can modify rules so ATs can conform to them -- could do with document tagging interface and adding arbitrary name value pairs to objects; problem with creating new interface is that it risks creating situation where AT has to switch mode of operation between a document and other applications

MM: that's the current state of affairs, at least on windows

BH: can get philosophical discussion here; for efficiency always need application specific scripts; want to avoid having to script because of differing implementations; scripting far more common on Windows than UNIX, but more scripting on UNIX currently than we want

RT: Collection interface exposes infinite space, and that's what is the problem -- benefits of not exposing preference counting and life-cycle leaks and such

BH: independent issue -- Collections won't continue that legacy or compound it

MM: we need to talk about that

BH: should probably take offline, but think a misinterpretation of Collection API

MM: that's the way it reads -- if i want to know from now until done with object

BH: agree -- danger of interface that exposes semi-infinite space -- client has to be careful to ask for boundaries; don't want too much of an implied contract about what happens from then on; have to clean up and specify behavior of Collection; early days of ATK allowed objects that are "state-transient", but didn't have to make use of that idea so not a lot of experience, but need to revisit for a complex document; makes sense for collection to not have side effect of increasing one's notification load; need to anticipate side effects

MM: need decent document interface so that can move by object or chunk

BH: Collection could be used for that, unlike rest of AT-SPI has transversal and ordering info in it not part of rest of AT-SPI; maybe isn't best way to expose that info, but designed to expose that information; documents not only things with traversal orders -- is a spreadsheet a document?

RT: giving application a means to know what it needs to keep "live" -- for visual user, what is on screen, but what does it mean for blind user -- no way to manage lifetime of objects in application; basically a viewport kind of idea

BH: not specific to what document means -- fuzzy crossover with UI; when comes time to apply ADoc always going to be easy to apply it

MM: question of space -- expose to user a larger space or whole space; standard GUI app with no scroll widows, straightforward, but once scrolling introduced, problems arise

BH: Collection's genesis was that viewport not sufficient for ATs; never took position pro or con, but significant number of developers felt that viewport not sufficient; viewports are useful

MM: perhaps we need to re-investigate

BH: traverse entire document and not what is on screen -- all chapter headings even if sighted user can only see one at a time

RT: how is that done currently -- find scrollbar for pane, and keep location in memory?

BH: goal of collection is that rather than have document presentation end at bottom of the screen or at end of current or next paragraph

WW: in Orca, we set the caret position and expect the caret to be put in visible area -- will force peers to be created; don't have to move scrollbar with AT, if can be done natively

MM: i have point of regard issues to discuss with WW

BH: currently difficult to collect all headings if no Table of Contents -- collection one potential solution -- don't need to enumerate beforehand what to expect

AG: 2 points: 1) Collection already comes in applications like microsoft Word -- not just for accessibility purposes; practical and actual history of bringing collections into accessibility API; was used and was very helpful in general; 2) AT-SPI went further than collections idea -- allowed for richer query language

'MM: base on Collection API -- want these objects and know about them until i close this collection might help solve viewport issue; careful not to mix questions: is collection API useful? (yes) and what is given to the AT for its UI

BH: ended up deciding that Collection interface would do some of the work; other in specially created interface called "document"; lion's share of work being done by Collection, but if revisit, may get balance somewhere else; if we can come up with Collection and Document Interface that can work in tandem without redundant interfaces or disjoint models (rules changing according to document type and content)

JS: next weeks' meeting specifically dedicated to Collections in move from CORBA to D-Bus -- want to retain what we've already built; will approach many of these points from a different point of view next week -- certainly plenty of fodder for a face2face

PB: could PK consider committing Sun resources in addition to Willie and Malta?

PK: I don't actually manage people, so can't direct them to do whatever i'd like -- i would invite WW and Malta in email to commit themselves to this work

WW: timing going to be hard; getting traction difficult

WW: what kind of funding does LF have for accessibility work?

JS: no specific accessibility fund; travel expenses funding available for those without institutional support; currently looking for grant money -- that's how we plan on proceeding with testing

WW: something similar needed for AT-SPI on D-Bus work

JS: yes

WW: need to speak about it

JS: Linux Foundation meeting at IBM in Austin in April a good opportunity to move agenda forward; could also take advantage of the presence of audio and desktop implementors

PK: D-Bus -- MM and CG -- one of you mentioned Novell being involved in D-Bus work-- did I hear correctly?

CG: want to be involved in it very much

PK: can you throw money at it?

MM: easier said than done -- wouldn't attempt by ourselves but seeking to work collaboratively

CG: funding needed for staff, not a general funding pool

PB: is Ariel Rios involved in collection at all?

WW: Ariel working with Scot Hager on work funded by Mozilla Foundation to support live regions and roles into Orca

PB: which component is Ariel working on?

WW: Collections interface and AT-SPI

MM: seems right module to do it in, but needs review

WW: page summary info testing with Orca, quicker way to traverse contents (header to header, list to list, list item to list item, object to object, etc.)

WW: Li Yuan doing fantastic work on AT-SPI -- stripping out bonobo from CORBA and just uses orbit

PB: any barriers other than time to Li's participating in these calls?

WW: participation in calls would be difficult, but the Orca team has been very impressed with speed and quality of his work

PK: Li Yuan may be in California during CSUN -- perhaps can do something there, although that;s a heavily loaded week

JS: this conversation to be continued (we are past the hour)

JS: without objection will post audio of conference call and alert list -- hope to speak to most of you next week, as well

Topic 3: Website Update

New Business

Identify Topics for 29 January 2008 Teleconference

Wrap Up

Summary of New Action Items

none logged

Summary of Continued Action Items

none continued

Summary of Resolutions

none logged