Note: These minutes have not yet been approved.
JS: brief items: still awaiting word on KarenC's contacts with MS about community promise; 2 reasons: 1) work jointly with AIA (contingent); 2) immediate need: 2 methods requested by MS in IAccessible2 - need to be sure that not under any type of IPR hatchet that may come back to haunt us
JS: KarenC made contact, but engineers cannot speak for company, so has to go through legal;
JS: anyone participating in hackfests?
IAccessible2 RFC concluded 30 June 2008; the SIG fielded a few comments; Pete Brunet and the IAccessible2 SIG have reviewed the comments, made slight changes, and have frozen the specification in preparation for the entire Open A11y Workgoup's approval. Once Workgroup approval has been obtained, IAccessible2, version 1.0.2 will be forwarded to The Linux Foundation's board for approval by our umbrella organization.
JS: here is what i propose: discuss any remaining questions or concerns; spec been submitted to WG from SIG; discuss today and vote next week -- objections?
PK: have you seen my email from earlier today
PK: fundamentally PB, WW, EJ were having side conversation to help me get clarity; some things need clearer documentation - suggested one thing to be deprecated; satisfied with outcome of conversation, so ready to vote this week
JS: announced vote for next week via email -- hesitant to vote today -- could vote by email
PK: not interested in delaying for sake of delaying, so
JS: move to vote next week?
PB: sounds fine -- will review PK's note after call and effect changes if needed; WW and i talking about returnsValid (check link to see if valid) and another on key-bindings
PK: should discuss in separate space, what of additions that came into IA2 should be brought over in what form to AT-SPI
JS: absolutely -- talked of having conversation after getting IA2 spec approved; looking to start conversation at end of October and beginning of November
JS: participants and times for follow-on conversation?
PK: Lee Wong essential -- might move meeting to accommodate him
JS: and NVDA participants, as well -- can come up with mutually agreeable time
JS: timeframe of IA2 AT-SPI conversation/synchronization/congruence?
PK: suggest take output of diff document that PB generated of updates to documentation and general email traffic and then have conversation, call in PB where appropriate
PB: sounds good
JS: start that when and by whom?
PK: GNOME 2.24 just released and it has issues that need to be attended to; i don't want to attempt to commit anyone else's time; pencil in for next main ATK/AT-SPI activity, but not put a date on it
JS: that is fine
JS: anything else relating to IAccessible2
JT: from AT developer's point of view -- very happy with what has come out; worked with IA2 community very well, and worked out well for us and for our consumers; early adapter and use as main API, not something implemented on side, so a strong vote of confidence from an AT developer
PB: good to hear especially since out-of-process with you guys
JT: what's there now is working very well; of course everything can be improved, but would not have had success we have had without IA2 and IA2 SIG
AA: going to talk about UIA -- only engineer working in D-Bus stuff is mike, but recently working on UIA; will give us status report -- very optimistic; mark finished polishing it, and should be prepared for testing soon
MG: fairly close to being close to being tested; working on bridge recently, but not concentrating on AT-SPI on D-Bus; coming along since MarkD working on it; working with accessciser on pyspi -- tests seemed initially positive; works without really needing to change API, but only testing one app at a time; done some work on registry, but not sure what status is - may be close to testing
AA: respect to D-Bus any questions?
PK: quick one: under impression that also Nokia involvement in D-Bus work?
MG: Mark with Rob Taylor at CodeThink and Nokia is funding CodeThink
PK: got it, thanks
AA: update on UIA team's upcoming plans; project seeks to implement UIA API on provider side to have accessible AT clients read WinForms applications in linux via mono; first release will be early December -- will be 0.9 release and will be synchronized with release of mono 2.2; after that, probably make internal beta release (help testing welcome); 1.0 release hopefully synchronized with release of mono 2.x hopefully as early as February March 2009
JS: bridge to ATK for testing to involve AT-SPI interface
AA: our tests indicate that starting to get WinForms apps seen by accessicer and orca recently - keys not being caught by API due to mapping problem with ATK, but with 0.9 will have usable release, but not all bells and whistles
JS: ready to play with applications?
AA: if include widgets and DOM, yes
JS: such as?
JS: does a11y.org link-to that resource?
GJR: it does now -- will add to test page
PB: how hard to re-purpose code to make IA2 to ATK bridge
AA: guess is quite difficult; focusing initially only on linux; haven't had much experience with IA2; MikeG may be better resource
PB: interfaces quite close -- best thing is to move to common environment that includes windows
MG: might have to write .NET bindings for IA2
MG: bridge would need to be reworked some
AA: 2 parts: binding and new special bridge to bridge the bridge
JS: congratulations -- a lot of exciting stuff to play with
AA: also wanted to mention that we are writing wiki page documenting issues we have found in mapping ATK/AT-SPI to UIA which we are going to propose to Microsoft
Background: Open A11y needs to schedule a meeting on the emerging architectural proposal for Expert Handlers, primarily with Linux/Unix developer community
JS: one more item; hoped NeilS, chair of Expert Handlers SIG would be here to deliver in person
JS: background: what caused us to create expert handlers WG: lot of Specialized MarkUp Languages (SMLs) for specific disciplines aimed at encoding knowledge specific to specialized content; sense was ATs would do well with generalized markup languages such as HTML, but not with specialized markup languages -- as has been the case with MathML; other SMLs user bases too small; question asked EH to look at is an approach to write a third-party plug-in so that would contextualized specialized markup for meaningful input and output; published Use Cases for Expert Handlers last spring and presented on Expert Handlers at CSUN
JS: Aaron Leventhal proposed use of ISimpleDOMNode - AT could handle itself or invoke expert handler so could be appropriately presented to user and from user to application;
JS: good reaction: re-purposes existing technology; promises quick prototyping; gives ability to expand upon it incrementally so can handle edge cases in well-formed standard manner
JS: yesterday had conversation with Glen Gordon of Freedom scientific -- bought into idea; going to canvas other AT developers
JS: thread - should linux use this approach or AT-SPI architecture -- want to get linux experts involved in expert handlers; want to see if can find time either at this call or at Monday's expert handlers calls to see if appropriate for AT-SPI
(scribe's note: NS joins call)
PB: IA2 a lot of work done with that to make as close as ATK/AT-SPI --- ISimpleDOMNode doesn't exist in ATK/AT-SPI - how would it work in linux; would it work in linux; sync between IEEquivalents, so need to get that in harmony with IA2 -- possibly in a third interface
JS: not just linux/unix that needs to consider approach -- possible answer is "great idea but not great enough"
PB: do we want to add something like
get_innerMarkup() to IAccessible2 to provide ISimpleDOMNode-type access?
NS: what Aaron suggested works for FF and potentially for Opera and Webkit/Safari, but issue with IE8; want it to be able to work with OpenOffice or Acrobat -- EH and AT would have to know about particular app; ISimpleDOMNode is good solution, but not panacea -- would like input from linux side
JT: still not convinced that having something like this in IA2 good idea; can represent DOM without needing another interface -- just expose all attributes -- ISimpleDOMNode predates IA2, but now IA2 can get attributes from any DOM
PK: why didn't go down this route a few years ago -- collection interface about doing searches; want something like this for ALL types of "rich" content -- makes more sense to have something more general, than to take approach that DOM-like content
JT: makes more sense to have superset than subset
PK: understand motivation for doing this is available in FF and AT in windows used to looking at DOM; eventually WebKit and Opera may come into line; but web an important and distinct medium, so understand arguments for immediate implementation, but not persuaded it is the best approach
JT: nor am i
MC: we just use IA2 so don't need a virtual buffer -- agree with PB that need some sort of markup to handle specialized content
JT: same for ATK; if IA2 gets it, ATK should get it; if have 3 implementors using ISimpleDOMNode, can use tree of IAccessibleObject; most other screen readers stuck with single DOM and don't want to change; our point of view is has to be progress at some point, and the earlier the better
get_innerHTML() is useful as the LCD approach, but by doing that cut off interactivity options of an expert handler, so can't say once do that, it is our solution; if build a11y tree that reflects DOM
PB: probably not useful for accessibility
MC: FF3 there are only a handful of cases where nodes are dropped; if helps for EH, then would ensure that FF recognizes every node
NS: what happens when NVDA encounters MusicXML -- default to expose all or do nothing?
JT: currently, nothing; FF needs to know how to render it
MC: doesn't treat accessibility tree as DOM
PK: at what point does FF or any User Agent figure out what to do with that markup?
NS: FF knows what to do for MathML visually; plug-ins currently provide accessibility; could be replicated in FF, but concentration been on IE
PK: whatever code being written to handle new markup could handle creation of accessible nodes in a tree; not clear to me that it makes sense to say, i've come across new markup, we either need to revise AT to provide raw access or need an expert handler; an expert handler is going to interact how with 5 different screen readers on the market for windows alone? seems more scalable and tractable if say bar for adding new markup in browser, just as new application, is that it needs to create accessible nodes;
JT: more than just making sure that accessible nodes for everything; need to do FF-centric things -- support IA2, but when represent HTML do what is most expedient; can have all accessible nodes but still need prompt from another place to interpret
MC: can put EH in application
JS: need for glossaries and pronunciations; different ways of brailling things; differences between normal speech and specialized speech; different types of nesting -- need to hierarchic nodes, but in SVG not a tree, but stack; whole raft of differences -- enough that need some specialized knowledge to represent, navigate (especially for alt input), and for editing/interacting with a specialized markup language
NS: in FF, MathML already rendered, SVG already rendered, so accessibility not necessarily tied to visual rendering; being able to take over is not a viable option
JS: probably case that most applications will pick up handling of MathML over time, but there are so many discipline-specific markup languages being developed; premise is AT is never going to cover all [[Accessibility/Handlers/References/SMLs|SMLs] -- always going to be choices; do we gain more if can come up with mechanism so that those who care/need to interact with specialized markup can; platform agnostic manner; leverage what is available and provide standard way to plug in, this will be a much bigger win than just MathML or SVG support
JS: come back to main workgroup because ISimpleDOMNode suddenly got a lot of interest from actual developers; problem still out there -- what to do with hyper-specialized markup languages -- should be part of toolkit available to students and everyone/anyone interested or has a stake (intellectual or other)
NS: would like to have EH be as independent as possible from an application, so can write EH based on markup language; like to have standardized interface for AT so don't have to worry about each application as far as generalized accessibility; could go further by extending ARIA roles; need standardized interface that exposes to AT and allows user to expose to SML via AT
PK: have to drop
(scribe's note: PK parts)
JS: will take to email the issue of continuing discussion on linux side? when to revisit?
(scribe's note: AL joins)
JS: should get AaronL in conversation as well and ask PK to bring whomever else he thinks would
AL: apologies for being late -- had wrong time for call
PB: working through alternatives -- what might be needed if added as new interface to IA2 aside from getting markup for that
JS: summary: PK, NS, JT, and MC on call -- fair amount of skepticism about need for ISimpleDOMNode or
AL: what if something interactive in tree
MC: should be able to get accessibility tree by walking nodes -- not sure need for another interface when accessible tree already a tree
AL: not married to solution -- thought might be quick short-cut; 3 other screen readers use ISimpleDOMNode - JAWS, SuperNova and ZoomText; they are primary consumers for ISimpleDOMNode; if Opera and others support ISimpleDOMNode thought might consider -- good way to express any XML-based info
AL: how to make sure object attributes exposing are DOM attributes as opposed to DOM-foo attributes
AL: provides balance and might want to expose balance for each node
JT: bit scary to hear idea about ISimpleDOMNode, because we thought the idea was to migrate to IA2, which is why supported IA2 rather than ISimpleDOMNode
AL: ISimpleDOMNode an additional thing -- never get you all the way -- rich editing would not be possible
AL: any reasonable web application needs to support IA2; ISimpleDOMNode also gives ability to drop down into content that UA doesn't support -- can get actual XML; so as NVDA stands today in FF3, if perceive math, can either handle directly or hand off to expert handler; in any event, need IA2 support
AL: just means of exposing XML and FF supports it
JS: next steps? think we have clarified approach as to how this might work
AL: was PK on call?
JS: dropped right before you joined
JS: big item next week is vote on IA2, so then have time to discuss GNOME developer conferences and/or IA2 and ISimpleDOMNode; want PK and Linux/Unix people on call when discuss; EH may live on web and be delivered via port 80 -- optimal goal
JS: October 28, 2008 for follow-up?
AL: fine for me -- far out, but works
NS: October 28 ok for me
JS: will meet next week to vote on IA2 and discuss whatever is most germane to attendees (GNOME summit feedback); Expert Handlers discussion will be on 28 October 2008; there will be no meeting on 21 October; next meeting 14 October 2008