From The Linux Foundation
Open A11y Working Group Conference Call (22 January 2008)
Contents |
Participants
- 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 http://www.oatsoft.org:
- The WindowCatcher project report provides a lot of detail too
- Steve Lee, post to accessibility@a11y.org (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:
- API issues related to documents, tables, revisions (Pete Brunet)
There may be overlap between the two IA2 topics, i.e.
- interfaces/methods needed for consistent document and table navigation, and
- access to higher level constructs such as spelling errors and revisions and the prior ADoc work and Collection interface work.
- I'd like to propose forming a subgroup of interested parties from the AT and application development communitieson both Windows and Linux to evaluate the two issues brought in from the IA2 group and the prior ADoc/Collection work so we can determine if there is some overlap and then identify the best solution.
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 a11y.org 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
- ADoc Documents Need an Owner
- still need reviews of:
- new descriptive text on the ATK/AT-SPI SIG main page
- new descriptive text on the ATK/AT-SPI Overview page
- status of extant ATK/AT-SPI Documents at Open A11y:
- tweaked ATK/AT-SPI Document Index
New Business
Identify Topics for 29 January 2008 Teleconference
- the 29 January 2008 Open Accessibility call will be dedicated to the topic of AT-SPI on D-Bus and the Collection Interface
Wrap Up
Summary of New Action Items
none logged
Summary of Continued Action Items
none continued
Summary of Resolutions
none logged
- meeting adjourned: 2023h UTC
- next Open A11y conference call: 2008-01-29