HTML Task Force Canvas Accessibility Subteam -- 17 Dec 2009

<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-20091030/

<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

<richardschwerdtfe> <default aria-activedescendant="foo"> /*Since canvas is visual this is

<richardschwerdtfe> the default mode. It contains the shadow DOM*/

<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*/

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 synthestic 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

HTML Task Force Canvas Accessibility Subteam

17 Dec 2009

Attendees

Contents

Media Queries and Selection of Alternative Content

Adaptation Types for Media Types

ATInteroperable

langaugeOfAdaptation

Summary of Action Items