<trackbot> Date: 07 August 2009

<scribe> scribe:Stevef

janina: how do we want to organise moving forward on canvas?

chaals: best guess creating a shadow tree in the dom, build relevant pieces of canvas

janina: can we agree that aria is going to be part of html5 and we can count on it for canvas?
... canvas work will be predicated on aria will be incorporated, put a stake in the sand

kliehm: lack of msaa support for new elements in html, AT see nothing
... testing for support needed, maybe steve can test?
... developers working with canvas have an idea of an object, but can't be done yet, just a bit map
... google using canvas rather than svg, because its faster, chaals said their is already a dom tree, but have to recerate it

q

<cyns> +1

kliehm: need to map objects painted on canvas

stevef: the current fallback method breaks down when any interaction and compexity is added to canvas

jcraig: agree complexity gets out of hand, biggest problem now is theoretical, there are no examples
... no good way to get shadow dom exposed
... better to let browser vendors work on providing access to shadow DOM and attempt to fix the potential focus management issues. otherwise, we may end up with a theoretical spec that isn't actually useful.

<jcraig> scribe: stevef

<kliehm> agreed

<Zakim> chaals, you wanted to say that the browser would do what it could, but we need to recognise taht in general it won't be good enough

cyns: 1 all browser vendors on this call

jcraig: using existing implementaions better than creating new pseudo-object model

<jcraig> jcraig: also, future js libs might abstract some of the potential onus on the developer.

cyns: noticded table API in HTML5, and wondered whether similar approach for cnavas may be useful/

jcraig: at the time you are drawing it javascript knows what it is, but dispaears once destroyed. nothing hangs around other than image data.

<chaals> CS: If there is a set of objects being built in creating a canvas, then that could be a place to hang an accessibility API.

<Zakim> chaals, you wanted to say timelines are important... which isn't necessarily in our favour

chaals: no objects in canvas, running with what we already have is better, inventing something new will take too long
... if we get libraries being built that facilitate accessibility, that will be good,the technology is poor because you have to doo a lot of the work yourself
... svg is sorta OK, but still problematic
... something we can do to help authors build an object tree, will help, but speed is an issue and developers vendors don't want to reduce canvas speed
... so we should go with ARIA and expect that ARIA 2.0 will provide more complete enhancements that canvas needs

<jcraig> Stevef: when I was looking into canvas, i thought about the similarity of image map

<chaals> steve: When looking into it, thinking of the similarity between an image map and working with a canvas.

<jcraig> Stevef: certain areas are interactive.

<chaals> ... you will have some basic elements that you can add roles and states to.

<kliehm> ach me

kliehm: enabling auto generation of text in a canvas, and need some structruers that cannot be mapped to ARIA or html

cyns: accessibility APIs are not new, lots of people who have worked on API's, so its not new territory
... v2 of ARIA, and it should have an API, and co developing it with html should be a reasonable thing to do

<Zakim> chaals, you wanted to say "duh", yes, that will provide some simple ones

<kliehm> we need to markup the shadow dom for some examples and see common elements like text, or perhaps things that cannot be represented by HTML and ARIA. No need to map it automatically now, just make an inventory of use cases.

chaals: we need an ARIA 2.0, that will help us make things easier, putting an image map on canvas will make things easier for simple things

<cyns> also alt and other WCAG 1.1.1 techniques covers many use cases

jcraig: vendors concerned about new web technologies, image map idea is an interesting idea since aria semantics could be tacked on to the image image dom elements

<cyns> http://esw.w3.org/topic/HTML/AddedElementCanvas#head-c43887ef27c016a20e53d16718ab16a398b6899d

janina: next steps for meeting, cllect a set of examples to further refine approach, its already in wiki page

jcraig: if browser has canvas it will not render anything inside cnavas

cyns: will speak to direct draw people at microsft

<chaals> stevef: not talking of using image map as fallbback

<jcraig> s/anything inside cnavas/anything inside cnavas to the accessibility api. we also need to think about how that should/could work

<chaals> ... using it as an idea of something tha culd be built in to canvas to handle focus management and provide a basic structure to hang ARIA from.

<Zakim> Stevef, you wanted to say i was not saying to use image maps, but to have something similar implemented in canvas

<chaals> ... if developers are creating interactions mouse-based, an easy win would be to create a form of focus that is natively accesible

<chaals> ... image map was an analogy

cyns: no approaches are mutually exclusive
... we can do all of these things, but need easy API as end goal

<richardschwerdtfe> what is the call in for this?

<janina> We're about to close!

<cyns> +1 to focus feature in canvas API.

<richardschwerdtfe> I was told the time was to start at 10 cst at the last call

<janina> edt

<richardschwerdtfe> it won't let me in

chaals: image map should not be an analogy, because image maps work now and can resolve some issues

<janina> probably because we're past the hour, and zakim was scheduled for 60 minutes

<richardschwerdtfe> this stinks

<janina> we missed you

<richardschwerdtfe> I was told the meeting was at 11pm est at yesterday's pf call

chaals: it is a technique that works out of the box today

<richardschwerdtfe> I can't get it

cyns: alt on area is gone?

<richardschwerdtfe> so, I saw a comment on canvas

<richardschwerdtfe> what was discussed?

<janina> we'll have pretty good minutes in about 5

chaals: i siad there is a change in the model of image maps that I think would be bad for this

<chaals> [I will not be available next week]

<richardschwerdtfe> what is the object model we would be staying with?

<richardschwerdtfe> there is no object model in canvas and one is needed

<richardschwerdtfe> putting an image map on canvas is a punt

<chaals> rich, the plan is to go with building a model based on aria (because we know it alrready, and we expect to have to make ARIA 2 in any case with stuff that is currently missing), with HTML image maps able to handle some simpler cases...

<chaals> well, it is a solution for some of the things we want, and it will work out of the bo.

<richardschwerdtfe> aria 2 is a punt

<chaals> we agree that there needs to be an object model...

<kliehm> rich, also we'll look at the Wiki examples to come up with use cases how the fallback DOM of those would look like.

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/agrred/agreed/
Succeeded: s/better to let browser vendors working on providing access to shadow DOM/better to let browser vendors work on providing access to shadow DOM and attempt to fix the potential focus management issues. otherwise, we may end up with a theoretical spec that isn't actually useful./
Succeeded: s/object/pseudo-object/
Succeeded: s/jcarig/jcraig/
Succeeded: s/once destroyed/once destroyed. nothing hangs around other than image data./
Succeeded: s/cnavas/canvas/
Succeeded: s/image map idea might be a solution/image map idea is an interesting idea since aria semantics could be tacked on to the image image dom elements/
WARNING: Bad s/// command: s/anything inside cnavas/anything inside cnavas to the accessibility api. we also need to think about how that should/could work
Succeeded: s/maps/maps that I think would be bad for this/
Succeeded: s/scribe: jcraig/scribe: stevef/
Found Scribe: Stevef
Inferring ScribeNick: Stevef
Found Scribe: stevef
Inferring ScribeNick: Stevef

WARNING: No "Topic:" lines found.

Default Present: Stevef, +49.699.435.aaaa, kliehm, Cooper, Janina, jcraig, Cynthia_Shelly, Gez, chaals
Present: Stevef +49.699.435.aaaa kliehm Cooper Janina jcraig Cynthia_Shelly Gez chaals

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 07 Aug 2009
Guessing minutes URL: http://www.w3.org/2009/08/07-pf-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report