<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> 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
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
<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
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
<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
RS: posted recently on this topic
<richardschwerdtfe> <default aria-activedescendant="foo"> /*Since canvas is visual this is
<richardschwerdtfe> the default mode. It contains the shadow DOM*/
<richardschwerdtfe> <div role="toolbar">
<richardschwerdtfe> <div role="tab" tabindex="-1" id="foo">
<richardschwerdtfe> <visual type="text"> /*Here we could place a long description or an
<richardschwerdtfe> alternative aria-enabled widget*/
<richardschwerdtfe> <tactile> /*This is in access for all and we could lose it for now for
<richardschwerdtfe> obvious reasons*/
<richardschwerdtfe> <olfactory> /*This is in access for all and we could lose it for now for
<richardschwerdtfe> obvious reasons*/
<richardschwerdtfe> <visual type="signlanguage">
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
RS: will need coordination call with CSS group
... types - different attributes
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 synthestic web
SF: media type queries has visual and tactile
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
<richardschwerdtfe> 4a. adaptationtype - Provide one or more of the following adaptation types:
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
RS: fully supports A11y infrastructure (ARIA+HTML5)
... important to say needs to be interoperable with at?
GJR: can't hurt
SF: fine with me
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
RS: thanks for coming with such short notice