- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Fri, 18 Dec 2009 03:50:57 +0000
- To: public-html@w3.org, public-canvas-api@w3.org
aloha!
thanks to michael cooper (thanks, michael!) the minutes from today's
canvas sub group teleconference are available as hypertext at:
http://www.w3.org/2009/12/17-canvas-minutes
and as plain text following my signature -- please note that the
participants list from the morning's meeting was conflated with
that of the canvas meeting; my head count is as follows:
* Rich Schwerdtfeger (richardschwerdtfe)
* David Bolter (dbolter) / scribe (first half)
* Steve Faulkner (SteveF)
* Gregory Rosmaita (oedipus) / scribe (second half)
please report any omissions, errors, clarifications and the like by
replying to this announcement on-list
please note that the following action items were assigned during today's
canvas call:
1. ACTION-4: davidb Get back with the Mozilla team to ensure there
are no issues with allowing standard HTML5 input controls in the
shadow DOM
[http://www.w3.org/WAI/PF/HTML/track/actions/4]
2. ACTION-5: David Bolter to ask if the use of contenteditable areas
for representing rich text with caret position in the shadow dom would
be acceptable for HTML 5 and canvas
[http://www.w3.org/WAI/PF/HTML/track/actions/5]
3. ACTION-6: Rich - address fragments versus entire pages as
alternatives with HTML WG members
[http://www.w3.org/WAI/PF/HTML/track/actions/6]
4. ACTION-7: Gregory - propose braille media type (as opposed to
simply tactile) or sub-type after consulting with Braille-in-DAISY
APH and others
[http://www.w3.org/WAI/PF/HTML/track/actions/7]
and that the following was resolved by the sub group:
RESOLUTION: stay with audio, visual and default in shadow DOM
in addition, sub group members and interested parties are referred to
LauraC's wiki page:
http://www.w3.org/WAI/PF/HTML/wiki/Canvas_Change_Proposal_Action_165
thank you, gregory.
_________________________________________________________________
HTML Task Force Canvas Accessibility Subteam
17 Dec 2009
Attendees
Present
Rich Schwerdtfeger, David Bolter, Steve Faulkner, Gregory
Rosmaita
Chair
Rich
Scribe
davidb, oedipus
Contents
* Topics
1. Media Queries and Selection of Alternative Content
2. Adaptation Types for Media Types
3. ATInteroperable
4. langaugeOfAdaptation
* Summary of Action Items
_________________________________________________________________
<richardschwerdtfe>
http://lists.w3.org/Archives/Public/public-canvas-api/2009OctDec/0057.
html
<davidb> scribe: davidb
rs: first we'll discuss the shadow dom, and what html elements are
going to be allowed in the shadow dom, and what is our keyboard model
<Stevef> davidb: whats the plans for bespin that you mentioned?
rs: activedescendant is one thing, but tab control is wanted
... tech issues?
Stevef: it is a bespin specific thing (not general solution)
rs: is there a problem with tabbing to a button in the shadow area?
db: i can look into that
sf: html5 has sliders spinbuttons etc
rs: the author has to capture the keyboard events and visually show
behaviour in the rendered area.
db: i can't think of any show-stopper problems
rs: david can you go back to mozilla and see if all renderable
elements can be used in shadow dom
<richardschwerdtfe> ACTION: davidb Get back with the Mozilla team to
ensure there are no issues with allowing standard HTML5 input controls
in the shadow DOM [recorded in
http://www.w3.org/2009/12/17-html-a11y-minutes.html#action01]
<trackbot> Sorry, couldn't find user - davidb
<scribe> ACTION: dbolter Get back with the Mozilla team to ensure
there are no issues with allowing standard HTML5 input controls in the
shadow DOM [recorded in
http://www.w3.org/2009/12/17-html-a11y-minutes.html#action02]
<trackbot> Sorry, couldn't find user - dbolter
<scribe> ACTION: bolter Get back with the Mozilla team to ensure there
are no issues with allowing standard HTML5 input controls in the
shadow DOM [recorded in
http://www.w3.org/2009/12/17-html-a11y-minutes.html#action03]
<trackbot> Sorry, couldn't find user - bolter
<oedipus> trackbot, status?
gr: i will create manually
<oedipus> http://www.w3.org/2005/Incubator/app-backplane/
<oedipus>
http://www.w3.org/2005/Incubator/app-backplane/XGR-app-backplane-20091
030/
<oedipus> ubiquity x-forms project was the model -
http://code.google.com/p/ubiquity-xforms/
<oedipus> could set up a google code group for the shadow DOM for
CANVAS and use development of shadow DOM as a follow-up activity to
the RWAB XG - jack jansen, charlie wiecha, jack boyer, mark birbeck,
etc.
<oedipus> something for the sub-group to consider
<richardschwerdtfe> RACTION: David Bolter to Get back with the Mozilla
team to ensure there are no issues with allowing standard HTML5 input
controls in the shadow DOM
<oedipus> one way to get an implementation
group: discussing activedescedant
rs: if there is a shadow dom element inside canvas... any issues?
db: nothing comes to mind
<oedipus> http://www.w3.org/WAI/PF/HTML/track/actions/4
rs: re bespin we could have a rich text area, and reflect it in the
UI.
db: i'm not sure that is a bad approach
<oedipus> gjr notes that was finally able to get action assigned to
rich in tracker - it is action-4
(http://www.w3.org/WAI/PF/HTML/track/actions/4)
rs: concerned about doing a caret api - too loaded an effort
db: yeah
<richardschwerdtfe> RACTION: David Bolter to ask if the use of
contenteditable areas for representing rich text with caret position
in the shadow dom would be acceptable for HTML 5 and canvas
db: i can ask web developers
<oedipus> http://www.w3.org/WAI/PF/HTML/track/actions/5
gr: rich web app backplane recommends followup activity, for shadow
dom, or canvas api...
... there is interest
... if we can do it correctly and show it is feasible then win.
rs: could use text field btw
sf: how are you suggesting the caret will be expose... on canvas root?
rs: will have to show visual focus on canvas (css)
sf: placing focus of control is diff from caret
db: yep
<Zakim> oedipus, you wanted to ask if this approach will enable
simultaneous exposition of canvas and alternative (for cognative and
low vision use)
<oedipus> scribe+ oedipus
<oedipus> scribenick: oedipus
Media Queries and Selection of Alternative Content
<richardschwerdtfe>
http://lists.w3.org/Archives/Public/public-canvas-api/2009OctDec/0056.
html
RS: posted recently on this topic - example code follows:
<canvas>
<default aria-activedescendant="foo">
/* Since canvas is visual this is the default mode. It contains
the shadow DOM */
<div role="toolbar">
<div role="tab" tabindex="-1" id="foo">
</div>
</div>
</access>
<visual type="text">
/* Here we could place a long description or an alternative
aria-enabled widget */
</access>
<audio>
</access>
<tactile>
/* This is in access for all and we could lose it for now for
obvious reasons */
</access>
<olfactory>
/* This is in access for all and we could lose it for now for
obvious reasons */
</access>
<visual type="signlanguage">
</access>
</canvas>
RS: what we have is CANVAS and different modalities (save tactile for
now) so can be chosen instead of default
... if have map rendered in CANVAS, may not be most accessible
solution - author can provide alternative modality in HTML and have
attributes based on access for all standards
... if ua has css media query and person wants features x, y and z of
visual interface, UA would swap entire content for canvas using
css-type attributes
... whole shadow DOM can be unloaded and use alternative rendering
instead
... similar proposal for VIDEO
... want to have one that has the AUDIO associated with it, or i can
choose audio version of canvas with self-voicing app - user being able
to select which they want
... problems: 1) same with MEDIA proposal - don't have all media
elements in html5 today, but can add them;
... definitely CSS media equiv fomat
... second problem: don't have all a11y properties included in
Access4All version 3
... alternative modalities - within can choose refinements based on
set of preompts - audio description, high contrast, caption -- even an
eBook
... don't have to accept all of these, but want to follow this
approach
... providing alternate content for CANVAS requires support for these
queries
... discussion with CSS group on this topic
SF: discussed earlier in main a11y TF meeting
... sounded as if no major problem to get keywords added to CSS media
queries
RS: best fit mechanism - if no exact match, there might be a better
fit than is default
SF: if not this, use this type thing?
RS: pretty much
... suggest additional query keywords to CSS media group
... can discuss in january
... want to know if approve of approach
SF: yes
GJR: yes
RS: will need coordination call with CSS group
... types - different attributes
<richardschwerdtfe>
http://lists.w3.org/Archives/Public/public-canvas-api/2009OctDec/0056.
html
RS: do we ant to call element DEFAULT or SHADOW
SF: some talk on list today about term shadow DOM - claim it is
invalid
RS: what if call it default because canvas is inherently visual
... first one in list is visual
SF: ok with DEFAULT
... doesn't make huge diff at this point
RS: visual media type - alternative visualization?
... not shadow DOM - if user chooses this, this is what is rendered
... can add properties about source, for example high contrast, etc.
SF: sounds reasonable
RS: alternative media types: visual, tactile, audio, and olfactory
the synethestic web
SF: media type queries has visual and tactile
<Stevef> http://www.w3.org/TR/css3-mediaqueries/
GJR: propose a "braille" media type instead of "tactile"
SF: no disagreement
RS: video and audio as alternative types
GJR: does text cover braille
RS: can have refinement of tactile - braille
GJR: .brl format?
RS: leave out tactile, and have GJR come up with proposal for braille
ACTION - Gregory - propose braille media type after consulting with
Braille-in-DAISY and others
<trackbot> Sorry, couldn't find user - -
SF: get base ones in now,
RESOLUTION: stay with audio, visual and defualt (shadow dom)
RS: if have alternative content, what it means is media type goes to a
source; currently is entire file, not fragment
... mash-ups deploy fragments on web
... current media types require entirely separate source; ideally
would like to have fragment
... if fragment, put in IFrame in document
GJR: IFrame a11y issues -- scrolling
... is the IFRAME itself resizable
RS: prefer to have via fragments pulled in rather than entire
documents
... may discuss on public-html
... need futher discussion beyond group
<scribe> ACTION: Rich - fragments versus entire pages as alternatives
address with HTML WG members [recorded in
http://www.w3.org/2009/12/17-html-a11y-minutes.html#action04]
<trackbot> Created ACTION-6 - - fragments versus entire pages as
alternatives address with HTML WG members [on Richard Schwerdtfeger -
due 2009-12-24].
RS: within media type, choose specific adaptation types
... from current internal version of IMS spec
Adaptation Types for Media Types
<richardschwerdtfe> 4a. adaptationtype - Provide one or more of the
following adaptation types:
<richardschwerdtfe> audiodescription
<richardschwerdtfe> caption
<richardschwerdtfe> signlanguage
<richardschwerdtfe> highcontrast
<richardschwerdtfe> transcript
<richardschwerdtfe> alternativeText
<richardschwerdtfe> longDescription
<richardschwerdtfe> haptic
<richardschwerdtfe> e-book
GJR: braille an adaptation of tactile?
RS: want to include all of this, or just pieces?
SF: introducing too much complexity - don't want to overburden
alternatives
... sounds complex and complicated
RS: can say visual sign language rendering of audio file - can leave
some out
SF: might as well put all in and pull out if necessary
RS: need to discuss with broader group
... can have 1 or more values for adaptation
<richardschwerdtfe> ATInteroperable
ATInteroperable
RS: fully supports A11y infrastructure (ARIA+HTML5)
... important to say needs to be interoperable with at?
GJR: can't hurt
SF: fine with me
<richardschwerdtfe> languageOfAdaptation
langaugeOfAdaptation
RS: needs to be addressed for CC and video
GJR: and for braille!
RS: please reveiw rest of posting and provide comments to CANVAS list
... next meeting 2010-01-07; time TBA
<richardschwerdtfe> next meeting is at January 7, 2010 - time to be
announced
RS: target date for having something for HTML WG is February 25, 2010
-- aggressive but going to try to meet it
SF: doesn't have to be set in stone - as much completion as possible,
but there is some wiggle room
[ADJOURN]
RS: thanks for coming with such short notice
Summary of Action Items
[NEW] ACTION: bolter Get back with the Mozilla team to ensure there
are no issues with allowing standard HTML5 input controls in the
shadow DOM [recorded in
http://www.w3.org/2009/12/17-html-a11y-minutes.html#action03]
[NEW] ACTION: davidb Get back with the Mozilla team to ensure there
are no issues with allowing standard HTML5 input controls in the
shadow DOM [recorded in
http://www.w3.org/2009/12/17-html-a11y-minutes.html#action01]
[NEW] ACTION: dbolter Get back with the Mozilla team to ensure there
are no issues with allowing standard HTML5 input controls in the
shadow DOM [recorded in
http://www.w3.org/2009/12/17-html-a11y-minutes.html#action02]
[NEW] ACTION: Rich - fragments versus entire pages as alternatives
address with HTML WG members [recorded in
http://www.w3.org/2009/12/17-html-a11y-minutes.html#action04]
[End of minutes]
_________________________________________________________________
Received on Friday, 18 December 2009 03:51:26 UTC