- 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:30 UTC