minutes: 6 December 2007 UAWG telecon [DRAFT]


minutes from the 6 december 2007 UAWG teleconference can be found online


and as plain text, following my signature...

the post to which Jim refers that was delayed in reaching the list due to 
networking issues, has finally reached the list and is archived at:


PLEASE NOTE the following resolution on UAWG meetings for the remainder 
of 2007 and the start of 2008:

   RESOLUTION: next UA WG meeting 13 December 2007 then no calls until 10
   January 2008 -- in the interim, IRC "office hours" will be held during
   the regularly scheduled meeting time to maintain momentum and continue
   collaborative efforts and communication between UAWG members

which means, on those days when no call is being held, members are 
encouraged to join the #ua channel on irc.w3.org to discuss developments,
progress on action items, etc. during the time normally allotted for the

as usual, any errors, omissions, misattributions or clarifications 
should be logged by replying-to this post...



                                   - DRAFT -
                          User Agent WG Teleconference

6 Dec 2007


   See also: IRC log [http://www.w3.org/2007/12/06-ua-irc]


          Gregory_Rosmaita, AllanJ, KFord, Cathy_Laws

          Peter_Parente, Jan_Richards, Kelly_Ford_(last_half)

          Jim Allan



     * Topics
     * Summary of Action Items

   <AllanJ> GR: fills in group on current PF - ARIA and namespace issues

   <scribe> ACTION: Kelly - write description of alternative viewport
   issues that have been repeatedly raised [recorded in

   GJR: CDF actions update -- been in touch with DougS, but hasn't had
   time to talk at any length about CDF implications for the DOM; have
   also been liaising with Kenny Johar (of Vision Australia and DAISY)
   who is in the process of joining CDF as DAISY representative on
   coordination of efforts

   <AllanJ> GJR: DAISY profile incorporated in CDF, would negate need for
   a DAISY plug-in

   <AllanJ> GJR: Discussing multiple DOMs with CDF, what needs to be
   there, communication between them, sharing information with a11y APIs

   <AllanJ> GJR: sharing collaboration between Open Accessibility, Web
   API, WAIPF, Ubiquitous Web

   JA: related to email i sent that no one has received -- native
   rendering which has crossover with CDF and SVG and MathML; grew out
   of HTML5 VIDEO element; if have HTML document with embedded SVG via
   the VIDEO element all controls have to be available to
   accessibility API
   ... video in SVG -- SVG player runs SVG content natively, so all
   controls and content should be communicated to a11y API

   CL: are they first in the DOM?

   JA: HTML5 proposal states supposed to be in DOM by browser

   CL: browser knows about content?

   JA: HTML5 native rendering of VIDEO (Opera has example)
   ... with SVG, have a different DOM or is it that if UA is rendering
   SVG natively, does UA DOM include all SVG information or are there

   CL: is SVG part of HTML DOM?

   GJR: if SVG is served as application, then it will use a different DOM
   than the HTML5 UA, but there is talk of SVG in text/html which would
   allow not only for SVG embedding, but rendering natively by the HTML5
   compliant UA through a single DOM
   ... CANVAS element (for immediate mode graphics) -- GJR objected
   because (1) there is currently no way to add semantic info to CANVAS
   and (2) i think it out of charter for HTML WG and should be handled by
   Graphics Activity; there a lot of support by developers because 3
   implementation/partial implementations
   ... DanC (co=-chair of HTML WG) asked PF for comment and advice on
   CANVAS that's something UAWG might want to investigate; plan is to
   discuss CANVAS element on wai-xtech, i believe

   CL: AaronL says: the SVG content in same DOM in FF -- don't expose it
   through accessibility API because don't know semantics for SVG unless
   the author has added ARIA markup

   GJR: widgetization of SVG

   JA: SVG elements in DOM with tree, but doesn't know semantics?

   CL: semantics = label or heading -- doesn't interpret SVG elements in
   DOM and no mapping to a11y API as in HTML; FF looking for ARIA roles,
   states and events; if declare something about SVG in ARIA should be
   available, but theoretical

   JA: could walk through SVG diagram - this is the spoke, this is the
   hub, this is the wheel

   CL: might have to extend ARIA with custom roles

   KF: with IE if have plug-in have to add custom MSAA support for SVG
   with extension; would have to do what flash does today in IE to make

   JA: if have SVG plug-in, it is up to SVG plug-in to report semantics; 
   rendered natively, does burden get shifted to author to add ARIA?
   ... info may be in DOM, but accessibility API doesn't know where it is

   CL: is same in IE -- show up in IE DOM?

   KF: don't believe so
   ... don't support directly

   GJR: this is where expert handlers would provide semantic
   interpretation and hand either to a11y API or directly to AT

   JA: have HTML elements, go in DOM, but something in UA knows semantics
   and has rules as to rendering, navigation, etc.

   CL: yes, UA knows a heading or table; has algorithms that map element
   types to a11y APIs -- never done in FF for SVG
   ... in HTML have a lot of a11y markup (alt, etc.) in addition to
   element type; what needs to be exposed to AT?

   KF: not enough info to reliably know what to expose

   CL: right -- how does it get exposed or navigated -- SVG falls into
   complex visualization issue (eclipse and topology diagrams with java

   KF: need to leave

   <AllanJ> GJR: there is work being done on 'expert handlers' - xml
   implementation, acts as intermediary between specialized markup and
   accessibility API

   GJR: http://www.linux-foundation.org/en/Accessibility/Handlers

   <AllanJ> CL: how does expert handler know what to expose to the a11y

   CL: how does expert handler know what to expose -- has to understand
   markup in context it is used

   ... platform agnostic, which is why plan on using XML as basis
   MLs -
   ... agree with JA's observation that it is a11y middleware
   ... generic handler defined XML Events 2

   <AllanJ> CL: SVG is not on either list, is it general or specialized

   <AllanJ> GJR: still being discussed.

   <AllanJ> ... thinks it would be general

   JA: dependency on CDF -- what do we need to say -- GL6 talks about
   infosets and DOM

   GJR: the ultimate fate of the "purpose" element for generic handlers
   -- XHTML2 WG which owns XML Events 2 has declared it is out of their

   JA: actionable items in handlers? not specific actionable handler

   GJR: build on generic handler architecture outlined in section4 of XML

   <AllanJ> JA: 'handler' - actionable, or informational, that is
   revealing content to the a11y API

   JA: could put burden on UA -- whatever exposes has to also expose to
   accessibility API -- burden on author to add ARIA

   GJR: burden going to be on authors shoulders to add ARIA support

   <AllanJ> GJR: ARIA markup acts as middle ware to expose info

   GJR: our requirement is that that a generic handler has to be able to
   communicate purpose of generic handler; right now only way is ARIA

   CL: agree and so does AaronL

   <AllanJ> GJR: generic handlers needs to convey purpose, and context -
   identity, integrity, intent, state,

   JA: up to author?

   CL: yes -- right now it is

   JA: future thinking -- put back on UA?

   CL: UA in that loop -- if author adds ARIA, UA needs to expose to a11y
   API; other way would be to develop specific markup to apply to
   multiple markup languages

   JA: if use a plug-in or separate rendering engine, falls on that
   component (RealPlayer, etc.)

   CL: not considered markup languages

   JA: except when rendering SMIL

   CL: a lot of proprietary implementations -- for XML based, ARIA an
   approach to take

   JA: any ideas as to where this needs to go -- anyone want to take an
   action to address this?

   CL: from UA p.o.v. need to include ARIA as something that needs to be
   exposed no matter what

   JA: GL6 would be where to state that -- implement interoperable
   programming interfaces -- specific checkpoint about ARIA? 6.2 says DOM
   access to HTML, XHTML needed -- should ARIA be a technique or be

   CL: 6.1 and 6.2 need to be re-reviewed as does content definition --
   think need to expand -- even though say XML, what is there is very
   HTML based; can't change XML infoset document, but can update our
   concept of XML content

   JA: glossary items only now

   CL: have action item -- one potential problem is we don't own infoset
   ... have to cover CSS, SVG, any XML-dialect/ML (generic or
   specialized) -- don't know how far can go until more work done on
   handlers and expert handlers
   ... will not be available for rest of year after next meeting

   JA: meet on 13 December 2007 -- next meeting after that provisionally
   on 10 January 2008 -- scares me to have month off;

   CL: face2face in february?

   JA: no

   GJR: perhaps can have IRC office hours when meeting would have taken

   RESOLUTION: next UA WG meeting 13 December 2007 then no calls until 10
   January 2008 -- in the interim, IRC "office hours" will be held during
   the regularly scheduled meeting time to maintain momentum and continue
   collaborative efforts and communication between UAWG members

Summary of Action Items

   [NEW] ACTION: Kelly - write description of alternative viewport issues
   that have been repeatedly raised [recorded in

   [End of minutes]

Received on Thursday, 6 December 2007 19:32:14 UTC