From The Linux Foundation
Revision as of 14:58, 25 August 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/08/18


  • Neil Soiffer (NS/chair)
    • Pete Brunet (PB)
    • Vladmir Bulatov (VB)
    • Glenn Gordon (GG)
    • 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/08/18

Resources for Review:

Brainstorming with Glenn Gordon of Freedom Scientific, continued

GJR: needs to amend last week's minutes with GG's clarification

NS: good call last week

NS: comment from Glenn - hopeful that whatever came up with would allow AT to differentiate itself to add "value added" proprietary -- does IAccessible2 and other specifications allow that

GG: not turn-key solution - providers of data which we can adapt to what suits AT; EH wants AT to be transparent in some cases - harder to figure out how to inject something useful when sent a speech or braille string

JS: if successful and end up with spec that provides set of interfaces whereby EH can be injected into AT and provide services for certain types of content - wouldn't be a math expert, a music expert, etc. - specification for a common API to plug together

GG: hypothetically, someone has written music EH; would like to add an additional bit of usability through AT; if EH gives us info in black box, doesn't give AT much room for enhancement

NS: not interested in going to level of detail to do own EH

GG: might or might not; MSAA is LCD of interfaces; can get info from MSAA or go to IE DOM and get broader, richer set of info, worth to Freedom Scientific to provide interface for that; may want to include EH for math because of prevalence; want to be able to build upon what EH offers us

VB: AT tech - explore, but user wants control or may not want control; expose something in DOM for exploration by user; EH may do speaking job by self

GG: not out of questions, but implies there is another option, i want to figure out what other option might work

VB: AT may have approximate interface to DOM - up to user or AT technology what to expose

GG: understand intent of EH WG to make easy

NS: what is intermediate ground? GG mentioned AT adding property info to speech generated from EH

GG: thought was EH rather than marking up for TTS, would mark up with set of well known attributes; someone has to do mapping to say some script is in different voice for subscript - speech string from EH could convey "this is subscript" AT could then say "always handle subscript in X manner" so user has control

NS: tagging that indicates part of structure from which it came

JS: list of tags to which can assign different presentation

GG: would change from discipline to discipline; left hand in one voice and right hand in another voice, user wants control;

JS: if tool doesn't provide, would make sense

NS: one concern of mine is: given the small resources AT vendors have, providing intermediate string they need to process, would that pose higher barrier to accessibility; alternative come-back, but not only way

GG: other form could then be an alt rendering, or pass-back to EH and have it process it

NS: bilateral path - get something back, another process either renders to returns to EH

GG: if make explicit part of process, alt will get lost

NS: every markup will have different things that are potentially configurable; some way to standardize markup for those things you want to do; standardize way to discover

JS: generate or dynamic

NS: how to know fraction or numerator coming back

JS: handler says "here is a list of things that are high level and things that describe them"

NS: group A writes handler for MusicXML and group b writes handler for MusicXML; too much choice?

JS: going to be at least 3 interfaces: expose navigation points (organized list even in case of non-hierarchical info and what are neighbors) -- something else that tells what could do in speech and how to speak them; same for braille, and possibly for fonts and magnification; synchronize via SMIL-type method

NS: don't think need to expose navigation points; navigation complex in SVG - 20 different ways to navigate from one place to another

JS: value added - VladmirB's tool does great job of that

JS: have choice

NS: chemistry formula, thousand navigation points in formula

JS: if linear list, useless - if group, and EH shows groupings, can navigate among 20 and then dive down into details

JS: flat lists are part of problem

NS: proposing generic navigation - tree that corresponds to navigation hierarchy

JS: tree is probably easy-to-agree-on useful structure

GJR: explains Access module model - especially the @order attribute added at request of SVG WG

GG: SVG hard - what are lines trying to convey

JS: user doesn't care about the individual strokes of a glyph -- don't care about strokes that compose character, but the character itself

VB: shouldn't force ourselves to generalize everything into one plane; no one forces us to make every ML act the same

JS: powerful - can deal with multiple circumstances that way

VB: specific case can be supported via certain property

JS: if can't map to model, may be in trouble as far as generic handler interface

VB: AT asks EH for model - EH says here it is; AT if don't have EH, do what can;

GG: another wrinkle: braille user moving by expression - expression short enough to accommodate expressions to left or right; might want to highlight current expression but also context

JS: agree - analogous to what would do on-screen for magnification

GG: not enough to add expert handler - not enough to say what is current one

JS: what level, what are siblings, can i localize, granularity

GJR: targetrole - can be very specific, but needs to be in document source

NS: may be that part of structure - measure may be element in markup, like fraction in MathML, so might not need to add role for all those things

NS: what happens when there is an implicit role?

GJR: default behavior is to respect markup language's native flow; implicit roles could be marked up using ARIA (either on-the-fly or through a mechanism such as that offered by [ Access Monkey]

NS: EH returns a DOM to AT that is different from DOM that is actually there - abstract DOM that synthesizes roles

GG: like that, but don't know what high-level functions on that DOM would be

NS: roles don't form a tree necessarily

JS: not necessarily; or may be different from tree in other contexts

NS: SVG non-connected tree with overlap, what not tree like in music case

JS: don't know how many top level parallel tracks one has - everything from single note part (solo piccolo - just sequence of notes arranged into bars and on up), but for full conductor's score, have multiple voices - in print are over-sized books - one measure typically takes a full over side page

NS: could filter data down, to what user cares about

JS: filter in different ways - couldn't braille all at once - piccolo player part manageable - if want to hear in context, synthesize all other parts, make piccolo center

GG: synthesize the sound of the piccolo or the notes

JS: sound -- MIDI model so get sound in context

JS: in sync with playing of 8 measures synthesized with MIDI want your part to stream by in braille display

JS: time is always a factor with music

GG: shows notes visually, but no real-time conversion to braille?

JS: some developers working on that - don't know if "real time", but mark Hakkinen worked on this

GG: as AT developers, like DOM approach, but danger in this - if custom DOM for each domain, then how is that different from saying parse domain specific content yourself

NS: navigation implicit

GJR: Element Traversal may be of assistance here

GG: couldn't you select multiple axes get list, and navigate up/down next/previous

JS: would work in music - other need is group these four in sync

GG: how in math? single axis?

NS: think only single axis for math - line broken?

GG: reasonable to say in math case if at top level and navigating by expression, when request expression, get a + b and a has sub-expressions, would get top-level expression

GJR: need to indicate that there is sub-grouping when navigating top level

NS: a + b as expression - Raman's Aster can do variable substitutions

JS: detail - a squared minus c squared equals b squared - not something you'd navigate to; could have 50 expressions to it

GG: parenthesized expression - move by parenthesized expression rather than within

NS: has been some studies on making math accessible; do people pay attention to structure, number or operators - use broad mixture of techniques; less emphasis on structure - focus tends to be on numbers and operands

NS: here is an expression spoken, what do you remember? people don't remember structure, but components of expression (numbers and operators)

NS: potential DOM filtered by roles to look at various axes of things to separate out what user wants; one DOM

GG: one DOM - like channel on mixer - want linear path through part 1 but not other 7, as opposed to all 8 -- different ways of navigating

NS: how would user say "i'm interested in piccolo" and not other stuff

GG: that is where AT stands out- not purview of EH provider; EH can provide ideas, but where ATs function different from one another but consistent across domains

NS: if provide DOM, no AT would actually do anything with it;

GG: if DOM can be structured generically enough to accommodate generic

GJR: Element Traversal specification: : This specification defines the ElementTraversal interface, which allows script navigation of the elements of a DOM tree, excluding all other nodes in the DOM, such as text nodes. It also provides an attribute to expose the number of child elements of an element. It is intended to provide a more convenient alternative to existing DOM navigation interfaces, with a low implementation footprint.

GG: CDF who implements interface

NS: if no compound DOM this would be pointless

GG: axis not part of this; presumes only 1 way to walk; no semantic info about breadth of child; at top level or three levels down?

NS: if have axis to pick out piccolo part, what doing for that? nothing

ACTION GJR: current work summary of XQuery to handlers list

NS: perhaps EH needs utility function that provides what AT needs

GG: people will do minimum implementation - needs to be tied to provision of sufficient

NS: don't want EH to do it its own way?

GG: right

NS: what to do with DOM - restructure or throw out some of groupings; EH could clean up DOM and present structured or flat one; for math, there

VB: over-write SVG with what want to be rather than parse SVG;

NS: another meeting on 25 august - break for labor day

GG: willing to do one more - should i wait until after some

NS: 8 September 2008 will have GG back