From The Linux Foundation
Revision as of 03:02, 27 January 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 (8 January 2008)

Note: An audio archive of this call in OGG format is available.


  • Janina Sajka (JS/chair)
    • Stew Benedict (SB)
    • Pete Brunet (PB)
    • Mark Doffman (MD)
    • Michael Meeks (MM)
    • Gregory J. Rosmaita (GJR/scribe)
    • Gunnar Schmidt (GS)
    • Olaf Schmidt (OS)
    • Rob Taylor (RT)
    • Will Walker (WW)
      • regrets: none logged

For Reference

Preliminary Items

Approval of Past Minutes

Action Items Status Review

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

Summary of Continued Action Items

Meeting Minutes

Topic 1: Proposed D-Bus Road Map for ATK/AT-SPI

For Reference:

JS: the main focus of today's meeting is to discuss Robert Taylor's Overview of DBus ATSPI Design

RT: D-Bus is the way we think the right way forward; strict seperation btw API design and IPC design; a lot of efficiency; should go ahead and have on D-Bus, designed to be efficient, API should be lightweight

WW: 2 questions: 1) impact on existing pyapi bindings for AT-SPI?

RT: behavioral differences

WW: such as things turning into asynchronous calls

RT: yes

WW: 2) keyboard events want to be able to intercept; asynchronous calls wouldn't allow -- what would intercept events and prevent from getting to application

RT: AT making the call?

WW: registry daemon sends out to AT for analysis and AT returns yes/no to "can you handle" -- should be using xvg extention, but not very well supported right now

RT: no reason why alternate input devices can't be accomodated -- linked to change events; 2 options: 1) asynchronous then call back; or 2) AT provide small bit of service to process info through AT

WW: can be seperate paths?

RT: absolutely

JS: Olaf and Gunnar -- did you have chance to listen to the audio from 18 december 2007 call?

OS: no -- need to catch up on email, too

JS: eager to hear OS and GS' responses / feedback

OS: main question is WW's question: manage to use PyAPI as much as possible; had discussion in past changing things in AT-SPI - work differently on D-Bus? been told by PyAPI users that it is very important so can continue using existing applications; makes sense to serious look at getting better performance; BH used to stress that would be more maintainable if used same protocol/API over the wire for communicatinos -- can be auto-generated, but think tech moving away from that; not fully automatible or

RT: everyone wraps around generated content already

OS: exactly; for me it makes sense to extract data that way -- sometimes things done differently on Labyrinth, etc., but not AT-SPI expert

WW: would like to hear the KDE side of the story

OS: interested in seeing solution supported by as many parties as possible; need GNOME on board; only use accessibility bridge with Qt; goal: get TrollTech, mozilla, and everyone else to agree on standard so KDE acts identically -- important to have unified solution

JS: summarizing from last call, general agreement is that move to D-Bus on GNOME is practicable and achievable in a time frame; RT provided a roadmap; also discussed that all stakeholders with interest are pariticipating in process; need to go back to Trolltech to get participation so that what we create for D-Bus over AT-SPI can be consumed by GTK, interoperable ATs, etc.

RT: thinking point on plan: some logic in dealing with IPC -- would Trolltech use that library or do they want to write themselves? D-Bus different from actual API exposed through PyAPI -- would Trolltech use pyAPI -- would they like a library that implements the API?

OS: short-term and medium-term, user application side which is more important from KDE point-of-view; needs to be simple to implement D-Bus messages in Qt library to write user applicatinos and key servers; then on KDE side, might be some very simple ATs that might be interested in using AT-SPI over D-Bus; as long as possible to get information from D-Bus, that satisfies main programming need

MM: proper caching needed; fast iterators -- requires at least some client code that should be shared; hide protocol, though

RT: written in code -- a difficult fit; did some interesting tests today -- how much info transported via AT-SPI -- every bit of data/AT-interface -- came to 5MB; might be sensible to have 2 trees in a file which would signal changes, very low overhead

JS: would a large OpenOffice document have more interaction?

RT: no -- what is currently on the screen

GJR: on windows there is also what is available via the java accessbridge

RT: not going to work with really large documents

JS: collection mechanisms to move to other parts without waiting for propogation

RT: collection doing another IPC round-trip -- perhaps can communicate data to AT at startup and then communicate changes to it; only call for round-trip when change

JS: trade-off -- someone parsing DAISY document with well marked up structure; can take 25 to 30 seconds to get open, but once opened fast and efficient

RT: trade-off

MM: trade-off

RT: can work around overhead problem by only presenting what is on page/screen can be parsed

JS: while processes running in background

WW: Orca wants to get things off screen -- does this proposal allow this?

MD: yes, but changes how works: audio output can only read one piece at a time, tactile display relatively small (smaller than viewable area on text-only screen) -- reasonable to limit to expose to AT what is visible to sighted person; new things become visable as flowed or moved to

MM: document navigation interface -- telling insides "i need x amount of data" - page down, navigate by title, etc.

WW: page summary on web -- how many links, all links, forms, etc. -- would this prevent that?

MD: problem is word "visible" -- reachable? accessible from what is displayed on screen

RT: huge web page may have thousands of links -- do you want to wait until entire page is loaded (entire tree walked) -- can have an interface that allows page summary, rather than exposition of document

WW: what Collection API supposed to do

RT: design decisions that go into collection base don't necessarily drive document/user interface

??: can still ask for infinite collection -- lifecycle of what is handed to AT can cause problems

RT: ajax trick - close down stream -- push more XML -- use same solution -- display what have to display and continue processing in background

??: how does reading an .odf document work using Orca? get scroll bar to move down?

WW: open a document, each paragraph its own object -- get me current paragraph, get me current caret position in paragraph and will read line or surrounding text; moves around document one chunk at a time; if whole thing not visible and do a "say all" operation, need what is not displayed

WW: not a PageDown operation, but one that keeps available to sighted person; when speech stopped, scroll display to where speech stopped; for screen mag, want to highlight chunks as go

??: expose things in bounds of document being accessed

RT: if do want to highlight text currently being spoken (low vision/dyslexic)

JS: very big deal

WW: problably use an extention for that

RT: wow -- a lot of hard work!

MM: not too bad

WW: whole seperate collection -- if MM wants to help, he's more than welcome

RT: can't go about in infinite space if only expose what is visible -- how many links, or whatever contextual info user wants

WW: is this problem any different than ATK? doesn't act differently with different transport mechanism

RT: how remove integer settings in processing -- document reading interface -- this is being exposed at this time

SB: lifecycle issue, then

??: caching useful -- tree navigation needs no round-trip

??: if have document one is reading, could make sense to trransfer entire contents of document to AT and then signal change; problem is current implementation -- expose part of document using an ATK widget

GJR: adobe access module model for acrobat reader very similar

RT: is there a better word than visible?

MM: hidden menus are fine, documents are the real problem

PB: manage descendent there to support this -- when handle on transient state object, not expected to be around forever; everything becomes potentially transient

RT: get notification when document changes

MM: AT has weak references to object in process

PB: access object and hold onto it; can reuse "visible" state from IA2

GJR: same syntax/verbiage used in WAI-ARIA documents (consult, for example, ARIA Roles and ARIA States and Properties)

SB: application chooses to hold onto something, can for as long as it wants; everything should be treated as transient

RT: everything treated as transient -- for the chrome, nothing changes (visible and showing states) -- still have one layer (hidden menus, context/popup menus) -- multilayer, what is within screen, point-of-regard would be shown in a11y tree

PB: performance optimization

JS: outline mode (for example, headers not contents)

MM: provide enough to renderer to enable AT to decide how to process

PB: use cases handled through traditional APIs?

MM: right

PB: XML API where can do queries

RT: hopefully finding headings and structure of document important for everyone; needs to be extractable for everyone

PB: Jon Gunderson's UIUC accessibility extention for FireFox a model; "SayAll" operation processed in realtime, ensure that point-of-regard (POR) maintained

MM: could do by caret tracking

SB: onscreen keyboard -- GOK has a means of generating list of links (finite)

RT: document interface: here is document, can ask sensible questions of it (small number of links, headers, etc.)

JS: collection API discussions very reminiscent of this discussion

SB: accessible document?

JS: there is an IBM initiative like that, i believe -- quick back-and-forth through D-Bus

PB: indirectly involved -- will fiind out what happened to that and report on list

JS: please do so can discuss in Open A11y workgroup conference call

WW: question for OS and GS -- need for community to work together, but didn't hear commitment to work on AT-SPI over D-Bus -- is that something KDE would be willing to do?

OS: for KDE use Qt code -- Trolltech people need to be included in conversation, so when use Qt library know that Qt will work with everything developed but don't have to write our own support -- fully support this iniatiative, and personally very pleased that it is going on; Trolltech need to implement in library

JS: Harald Fernangle no longer in this area -- has anyone taken ownership?

OS: will contact Knute again -- exciting stuff close to what they are doing -- what is missing is collaborative effort

JS: need to know that what we do accomplishes what they need

SB: contacts at Trolltech -- will dialog with them

JS: we should go as high up the management chain in Trolltech as possible, so can ensure that things are synchronized -- we have a unique opportunity to make this happen now

RT: everyone in agreement with overview? should we push forward?

RESOLVED: Robert Taylor's overview/roadmap for AT-SPI on D-Bus will be basis upon which work will move forward.

SB: next question is "how do we fund it" and "who do we want involved"

RT: well, you have the 2 worker bees at CodeThink, but of course, we would welcome anyone else's participation

SB: begs question if AT-SPI cross platform, should we remove it from GNOME

RT: may be political issues at

SB: more mature spec needs to be taken out of GNOME space and moved to

RT: good idea in terms of writing specificiation on how IPC should act

SB: need consensus that this is right thing to do, and then tackle funding

RT: initial investigation funded by Mozilla Foundation; can apply again

WW: all positive -- OS, GS, RT, Mark and everyone thank you

JS: walkaway from today other than contacting contacts at Trolltech to let them know what is occuring here and need to take opportunity to synchronize

JS: accessible document format people's use cases -- don't want to loose what worked so hard on in CORBA

RT: create small window, set alpha channel to background (zero) if draw to it, selection indicated;

PB: one alpha channel then?

JS: what about multiple on-screen panels?

RT: may be unforseen problems

JS: a lot of power in documents for that -- those with dyslexic/LD

New Business

Identify Topics for 15 January 2008 Teleconference

JS: thank you all for attending today -- another great meeting; next week can try to have collections conversation; need to continue to invite people to conversation so as to broaden consensus as much as possible

RT: want to hear from Aaron Leventhal

JS: unfortunately aaron wasn't able to attend this afternoon's meeting, but he will be expressly asked to attend the 15 January 2008 meeting

Wrap Up

Summary of New Action Items

none logged

Summary of Continued Action Items

Summary of Resolutions