User Agent WG Teleconfernce

6 Dec 2007


See also: IRC log


Gregory_Rosmaita, AllanJ, KFord, Cathy_Laws
Peter_Parente, Jan_Richards, Kelly_Ford_(last_half)
Jim Allan




<AllanJ> title: UAWG telecon

<scribe> scribeNick: oedipus

<scribe> scribe: Gregory_Rosmaita

<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 http://www.w3.org/2007/12/06-ua-minutes.html#action01]

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 cross-over 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 accessibilityAPI
... 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 multiples

CL: is SVG part of HTML DOM?

GJR: if SVG is served as application, then it will use a diffent 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 avilable, 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 plugin have to add custom MSAA support for SVG with extension; would have to do what flash does today in IE to make accessible

JA: if have SVG plugin, it is up to SVG plugin to report semantics; if 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 adddition 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 applets)

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 api

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

GJR: http://www.linux-foundation.org/en/Accessibility/Handlers/References/MLs
... platform agnostic, which is why plan on using XML as basis
... http://www.linux-foundation.org/en/Accessibility/Handlers/References/SMLs - http://www.linux-foundation.org/en/Accessibility/Handlers/References/GMLs
... agree with JA's observation that it is a11y middleware
... generic handler defined XML Events 2 http://www.w3.org/TR/xml-events

<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 purview

JA: actionable items in handlers? not specific actionable handler

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

<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 specific

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 availble 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 place

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

rssagent, create minutes

Summary of Action Items

[NEW] ACTION: Kelly - write description of alternative viewport issues that have been repeatedly raised [recorded in http://www.w3.org/2007/12/06-ua-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/12/06 19:14:13 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.128  of Date: 2007/02/23 21:38:13  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: oedipus
Found Scribe: Gregory_Rosmaita

WARNING: No "Topic:" lines found.

Default Present: Gregory_Rosmaita, AllanJ, KFord, Cathy_Laws
Present: Gregory_Rosmaita AllanJ KFord Cathy_Laws
Regrets: Peter_Parente Jan_Richards Kelly_Ford_(last_half)
Agenda: http://lists.w3.org/Archives/Public/w3c-wai-ua/2007OctDec/0057.html
Got date from IRC log name: 6 Dec 2007
Guessing minutes URL: http://www.w3.org/2007/12/06-ua-minutes.html
People with action items: kelly

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report

[End of scribe.perl diagnostic output]