- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Thu, 6 Dec 2007 19:32:00 +0000
- To: w3c-wai-ua@w3.org
aloha!
minutes from the 6 december 2007 UAWG teleconference can be found online
at:
http://www.w3.org/2007/12/06-ua-minutes.html
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:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2007OctDec/0063.html
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
teleconference...
as usual, any errors, omissions, misattributions or clarifications
should be logged by replying-to this post...
gregory.
---------------------------------------------------------------------
- DRAFT -
User Agent WG Teleconference
6 Dec 2007
Agenda
[http://lists.w3.org/Archives/Public/w3c-wai-ua/2007OctDec/0057.html]
See also: IRC log [http://www.w3.org/2007/12/06-ua-irc]
Attendees
Present
Gregory_Rosmaita, AllanJ, KFord, Cathy_Laws
Regrets
Peter_Parente, Jan_Richards, Kelly_Ford_(last_half)
Chair
Jim Allan
Scribe
Gregory_Rosmaita
Contents
* 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
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 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
multiples
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
accessible
JA: if have SVG plug-in, it is up to SVG plug-in 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 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
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/M
Ls
... platform agnostic, which is why plan on using XML as basis
...
http://www.linux-foundation.org/en/Accessibility/Handlers/References/S
MLs -
http://www.linux-foundation.org/en/Accessibility/Handlers/References/G
MLs
... 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 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
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
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]
_________________________________________________________________
Received on Thursday, 6 December 2007 19:32:14 UTC