The Linux Foundation

 
Accessibility/Minutes/Minutes20081007

From The Linux Foundation

Revision as of 19:15, 14 October 2008 by Oedipus (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)

Open A11y Working Group Conference Call (7 October 2008)

Contents


Preliminary Items

Participants

  • Janina Sajka (JS/chair)
    • Andrés G. Aragonese (AA)
    • Pete Brunet (PB)
    • Mick Curran (MC)
    • Mike Gorse (MG)
    • Peter Korn (PK)
    • Aaron Leventhal (AL)
    • Gregory J. Rosmaita (GJR/scribe)
    • Neil Soiffer (NS)
    • James Teh (JT)
      • regrets: none yet logged

For Reference



Approval of Past Minutes




Meeting Minutes

Note: These minutes have not yet been approved.

Brief Notices & News

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?

AA: yep



Topic 1: Resolving Outstanding IAccessible2, version 1.0.2 Issues

IAccessible2 Background

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.

IAccessible2, version 1.0.2 (RFC version):
IAccessible2, RFC version 1.0.2 in HTML
IAccessible2, RFC version 1.0.2 as IDL
Errata for IAccessible 2, version 1.0.2

Recent Developments:

IAccessible2 Discussion

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



Topic 2: Two Reports From Novell: D-Bus Port Progress and UIA

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: questions?

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?

AA: going to update main wiki page of project; please also check the mono project's roadmap

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



Topic 3: Preliminary Expert Handlers Architecture Proposal

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

NS: 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

JT: choice

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 get_innerHTML() or get_innerMarkup()

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



Topic 4: Website Update (informational)

Recently Added Resources




New Business


Identify Topics for 14 October 2008 Teleconference

  • approval of IAccessible2, version 1.0.2 (formal workgroup vote)
  • Gnome Developer Conference A11y Discussions feedback


Wrap Up

Summary of New Action Items

Summary of Continued Action Items

Summary of Resolutions

  • RESOLVED: The Open Accessibility Workgroup will vote on IAccessible2, 1.0.2 at its (next meeting, 14 October 2008
  • RESOLVED: Discussion of Expert Handlers architecture and Linux/Unix will be continued at the 28 October 2008 Open A11y call





[Article] [Discussion] [View source] [History]