From The Linux Foundation
Revision as of 23:09, 17 November 2008 by Oedipus (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Minutes of the Open A11y Expert Handlers SIG Call 2008/10/06



  • Neil Soiffer (NS/chair)
    • Pete Brunet (PB)
    • Vladmir Bulatov (VB)
    • Glen Gordon (GG/Freedom Scientific)
    • Aaron Leventhal (AL)
    • Gregory J. Rosmaita (GJR/scribe)
    • Janina Sajka (JS)
      • regrets: Alexander Surkov

Agenda Review

Approval of Last Meeting's Minutes

Minutes of Expert Handlers Conference Call 2008/10/06

Topic 1: Conversation with Glen Gordon & Aaron Leventhal

NS: summary of last week's discussion with AL

  1. AL talked about FF's ISimpleDOMNode which provides relatively simple interface to implement in FF, will be done for Opera, may be done for Safari/Webkit -- web developers have said "this is good" -- way for an AT to go through tree and with own mechanism query for an EH -- pass of IDOMSimple interface to EH, removing application obstruction, can then do what needs to do in DOM
  2. AL also addressed possibility of a query interface to get other interfaces, but that gets into application specific issues

JS: need to talk about ISimpleDOMNode with linux developers at main Open A11y call

AL: don't know about [ WebKit], but Opera been working with Mozilla on ISimpleDOMNode -- may be more powerful than realize if AT vendors using it -- could be used to expose math or other content and could be solution for EH

GG: interesting -- leaving up to AT -- i can see content, can deal with it, or need to pass off to EH -- easy and transparent

NS: want an option to allow AT to call specific EH to have value added;

NS: need to have standardized interface for EH so can plug in if choose to use rather than different calls for diff specialized markup

GG: sounds fine -- use an interface that already exists

NS: 2 interfaces:

  1. talk to application to go through to DOM;
  2. query for handlers and use EH to talk to DOM

GG: IE and other applications don't support, so someone would need a bridge

AL: no matter what interface we create, IE would need to support; here is interface implementors have which can kill 2 birds with one stone

AL: expert handler could deal with IE DOM itself -- EH could be smart enough to abstract away if IE DOM or ISimpleDOMNode

NS: ISimpleDOMNode closer to what we need -

AL: structure still the DOM

NS: EH ideally single standard -- bridge

AL: bridges can be buggy - if write EH, would just consume DOM interface

NS: different interfaces that get passed in

AL: all implement IUnknown

NS: still need to know which

AL: query service - walk down possibilities

NS: Acrobat and Adobe Reader have something similar to ISimpleDOMNode

GJR: XQuery

PB: relationship between ISimpleDOMNode IA2 and MSAA?

AL: common interface - simple interface for sub-set of DOM tree in FF has IAccessibleObjects, even smaller have AccessibleText interface, but every node supports ISimpleDOMNode -- just giving you markup and style info

PB: can do today?

AL: yes, supported for long time in FF; if JAWS sees math element, can pass onto EH in ISimpleDOMNode to parse MathML itself, or navigate tree first and investigate one node at a time, when reaches something non-math, goes back to ISimpleDOMNode if link in math

JS: if get to object that is no longer math,

AL: this subtree is math, next node is not; what is inside of fraction, might have text field, so then go back to HTML namespace

NS: technically not legal in MathML but FF can do it

AL: how is that possible

NS: based on DTD - namespace aware

GJR: can DOM-bindings for MathML leveraged - when get to tag not math, go back to ISimpleDOMNode

NS: Compound Document Formats (CDF) punted on that in their CDF Reference by Framework -- no standard on how documents react

AL: HTML5 defines it now

GJR: yes, but HTML5 delivery date is 2012 -- can't wait that long -- proliferation of specialized markup languages, as i've attempted to document

NS: how does HTML5 deal with MathML namespaces

AL: use math tag

for reference:

* [ MathML in HTML5]
* [ SVG in HTML5]

AL: without namespaces, needed to find way to work --

NS: under impression SVG people didn't want anything to do with this

GJR: there is a "new" SVG Interest Group (SVGIG) devoted to accessibility and interoperability (scribe's note: please consult the next section, which contains extensive links concerning the SVGIG and its accessibility work)

GG: devil in details; fine until delegate back; not only passing off to EH, but EH now either passing back to you, or taking care of itself; how will know to fire link if click on it

GG: fine until mixing of namespaces

AL: what else will work better? expert handler for math, someone should write a BSD library for screen readers to put into code and them put proprietary stamp on it

GG: we're not pushing for EH solution; brought in to provide insight and if would ever use, and answer is yes, we might - happy with EH as solution; might be good in first go-around does not address other functionality - get main functionality working first

JS: solve more core issues without dealing with edge cases - then take them on item by item as EH matures

AL: at first ISimpleDOMNode could be re-purposed to get mathml string and pass back speakable string

GG: better off passing simple string?

NS: problems navigation wise

AL: allows to scale up and improve solution over time

GG: great

GG: not that wouldn't use EH, but not calling for it or feeling lack of *** for EH except for math

NS: no one asking about SVG?

GG: neither one has gotten folks knocking down door, but i think Math higher priority than SVG

NS: ad hoc solutions for each type of specialized content or standardized interface

GG: standardized interface preferable, of course

NS: vision that i have is that there be some generic standardized interface with extended capabilities

GJR: new LC draft of SVG Tiny 1.2 which the Protocols & Formats WG of W3C has been asked to review

GJR: un-self-minuted description and discussion of modularization and RWAB XG work

JS: who will be at TPAC?

NS: i will, but maybe not on wednesday - at different conference in Milan first part of the week

NS: where are we? general agreement that this approach is reasonable; have to nail down what EH would be to AT

GJR: next step will be requirements and roadmap document

NS: good next step -- will help nail down interface issues

GJR: build upon UUC1

JS: suggest plan some time to canvas for additional buy-in; linux community

GJR: also Debi Dahls' group at W3c (UbiWeb/MMI)

JS: canvas for ideas and support

AL: questions on IA2 list about using ISimpleDOMNode -- should start thread -- talked with Glen and think this is good way to go

ACTION GJR: set up wiki page on leveraging ISimpleDOMNode (done)

Topic 2: SVG Interest Group Accessibility Activity

Topic 3: Roadmap and Requirements Document for Expert Handlers

  • Requirements and a Roadmap document are definitely the next steps to take, but before the drafting can begin, the Expert Handlers SIG needs to address architecture and framework issues and alignment with those working on ATK/AT-SPI

JS: wrong thing to do is requirements document before putting out to other developers

GJR: for what it is worth, the standardsnistas at W3c are very enthusiastic

AL: topic for IA2 meeting?

PB: possibly

JS: plan to bring up on tomorrow's main call - linux conversation when - this monday slot, main slot, re-fired AT-SPI group

AL: SVG case - ISimpleDOMNode gets all ARIA attributes

GG: why can't you theoretically have EH pre-process the page, like a proxy, and add markup that could be consumed by AT

JS: long bit of markup in musical score would need pre-processing due to density of content

AL: if AT gets ISimpleDOMNode, and EH translates into markup tree, adding ARIA markup where available, AT then gets markup tree with node notification

GG: need to parse in different way - of EH pre-processes UA-independent, and AT only has to support ARIA

AL: put [ aria-labelledby] on nodes

GG: may want to configure sorts of things needed

AL: want to use same EH in OpenOffice or equation editor

AL: could pass EH ISimpleDOMNode, and return ISimpleDOMNode to return navigable steps - math as chunks

JS: important for alternative input AT

NS: still dubious that can -- can markup with text strings for each node

AL: can make up what ARIA we need -- extensibility mechanism built-in; aria-cycle-type=heading - just DOM attribute

GJR: if follow in-built extension mechanism, should be ok

AL: accessibility spackle

NS: only useful if AT and others buy in on this

NS: extent of support for ARIA?

GG: increasing - supporting where ARIA roles can be mapped to existing roles; don't yet support extension method, but could and would

GG: infrastructure is such that given specific ideas, could turn around quickly; mechanics relatively straightforward

AL: biggest thing to do is make as easy as possible; never going to be magic solution

JS: and will allow EH to support new dialects

NS: fall-back bEHavior - some sort of minimal accessibility, or is it all or nothing

AL: 1) javascripted web page - doesn't matter how much aria add - won't make work; 2) can create tree view and make look like list of nested links to older versions of JAWS but newer versions can interact like tree view

NS: don't want AT to worry - either a handler or no handler; if mark tree up, up to AT to implement or not

AL: you mean DOM tree

NS: yes, marked up with ARIA

GG: functionally standards, but want to add own inflection

NS: AT always free to do all work EH would do anyway

GG: if i get middle ground - marked up in canonical form - will be VERY happy

NS: concern is, user at mercy of all ATs to do something; if EH, only one thing that needs to be done to get functionality from EH

AL: all we need is to get one AT to do this right, then all ATs will follow; push envelope and have higher expectations - expect AT to do more than simply speak a string

NS: not clear on AL's thinking: 2 positions: 1) EH marks up tree and AT uses markup to do something; 2) EH goes and does full functionality, but in either case need EH or nothing will happen and in either case AT able to tailor EH experience; in first case where EH operates to one standard, works for everyone - more of win than EHs that need to be written, don't do the entire job

GG: as AT, there is incentive to use something that fits architecture using; ARIA far more appealing than something that turns things over to black box; may implement own or variant - more cooperative mechanism than delegation mechanism

NS: biology markup EH can be created without using ARIA mode, does something sensible, supports EH framework; but if come up with something that relies on ARIA markup, users have to get individual AT to implement

AL: EH standard for whatever content, best solution

JS: up to market, but should be up to individual user to use EH developed by biology department of university X

AL: making progress --

NS: agreed on one side of things, now arguing other side

NS: specialized sub-classes of EH handler interfaces (IEH?)

AL: doesn't have to be done with aria - expert handler can live either down the chain where AT calls it, or up in browser beforEHand and mark it earlier, then AT doesn't need to pass DOM on and get back; ARIA provides more flexibility

JS: existing technology already implemented; solves a lot of problems early on and provides path for extending it

NS: should explore both directions: 1) ARIA markup standardized that EH would implement and ARIA markup for specific SMLs; 2) interface with general user functionality that all EHs need, then sub-functionalities for richer experience; perhaps map 1-to-1

AL: ARIA just way of adding parameters and info; what info does AT want to consume from EH and what does EH want to provide; every chunk navigate to might need text to be spoken and sent to braille display; AT needs to determine localization

GJR: AT should know what is available to it

NS: issue of invoking EH; issue of minimal set of functionalities provided by all EH and all AT;

AL: back to need set of requirements and what SR wants from EH; need to bring up ISimpleDOMNode to rest of group; that seems to be point of agreement

AL: IE does have DOM subtree -- EH could use that; binary EH could consume IE DOM and deliver ISimpleDOMNode

JS: what is AIA doing in this regard?

AL: different content, but all XML or XHTML based - in end boils down to DOM

NS: top of hour - how to proceed?

NS: will be here 13th - not 20th or 27th

NS: schedule meetings and find out who needs to join

GG: have to run, but if have enough advance notice, i'll show up

AL: if have enough advance notice, i'll show up too, and let me know about IA2 meetings

NS: thanks GG and AL for

JS: go back to other ATs - linux ATs, ZoomText (IASquared), NVDA -- talk to as many people now before requirements written

NS: next week?

JS: won't be here - Columbus Day - US holiday

NS: making good progress -- hate to take 3 weeks off

JS: not available for 20th (TPAC)

NS: can make for 13th, but not next 2 weeks

PB: GW-Micro

VB: no preferences

GJR: maybe trying to get david bolter on input side?

JS: pick that up when linux conversation on EH starts

NS: will try to get Doug Geoffrey to attend next meeting

NS: like to get more requirements down: if go aria route, here are properties; if go through interface route, this is kind of interface method

JS: distinction?

NS: 2 technical means of achieving the same thing

JS: stuff need to achieve

NS: if talking to AT vendors asking what willing to report - if several make commitments on ARIA and think this would be good test case, then pursue that, but not sure right way to go

NS: tree view onto list view will be used a lot

JS: invite them to participate in that decision

JS: we have an emerging proposal and want to talk to Doug G again

JS: when can we discuss with linux folks

NS: will try and make tomorrow's main Open A11y call