See also: IRC log
<trackbot> Date: 07 August 2009
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 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
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
... 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
<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/
<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
... 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
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
... 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
<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[End of scribe.perl diagnostic output]