W3C home > Mailing lists > Public > public-html@w3.org > December 2009

minutes: html5 a11y task force canvas sub group telecon minutes 2009-12-17 [draft]

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
Message-Id: <20091218034135.M50685@hicom.net>
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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:55 UTC