19:59:43 <RRSAgent> RRSAgent has joined #html-a11y
19:59:43 <RRSAgent> logging to http://www.w3.org/2010/02/01-html-a11y-irc
19:59:45 <trackbot> RRSAgent, make logs world
19:59:49 <trackbot> Zakim, this will be 2119
19:59:49 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
19:59:51 <trackbot> Meeting: HTML Accessibility Task Force Teleconference
19:59:53 <trackbot> Date: 01 February 2010
20:00:09 <richardschwerdtfe> chair: Rich
20:00:33 <richardschwerdtfe> meeting: W3C HTML Canvas Accessibility Meeting
20:00:36 <jongunderson> jongunderson has joined #html-a11y
20:01:03 <richardschwerdtfe> just a sec
20:01:05 <richardschwerdtfe> coming
20:01:19 <frankolivier> frankolivier has joined #html-a11y
20:02:38 <Zakim> +Rich
20:02:54 <oedipus> zakim, who is here?
20:02:54 <Zakim> On the phone I see [IPcaller], Gregory_Rosmaita, [Microsoft], ??P4, Rich
20:02:54 <Zakim> On IRC I see frankolivier, jongunderson, RRSAgent, richardschwerdtfe, oedipus, Stevef, MichaelC, davidb, Zakim, trackbot
20:03:20 <davidb> i can't dial in yet
20:03:39 <frankolivier> frankolivier == [Microsoft]
20:03:47 <richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0144.html
20:03:50 <oedipus> zakim, Microsoft has Frank_Oliver
20:03:50 <Zakim> +Frank_Oliver; got it
20:04:14 <oedipus> scribe: Gregory_Rosmaita
20:04:18 <oedipus> scribenick: oedipus
20:04:27 <oedipus> TOPIC: Action Item Review
20:04:29 <Stevef> oedipus: ip caller is me
20:05:15 <oedipus> FO: super simple mock-up -- not rocket science but a bit of work author has to do -- more than alt text on img, but fairly straightforward; if map controls bnack to HTML UI elements, easy to do
20:05:26 <oedipus> RS: no problem with focus mangement and drawing image?
20:06:04 <oedipus> FO: did simple - 2 checkbox example; text boxes more intricate, but follow same pattern; as control gets more and more complex have to do more mapping, but that doesn't mean it isn't feasible
20:06:11 <oedipus> RS: looking at it
20:06:36 <richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0147.html
20:06:59 <oedipus> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0147.html
20:07:46 <oedipus> FO: if ignore shadow  dom still visible, this is like JCraig's example; if pretend shadow DOM not there, to AT would like like 2 checkboxes; all interactive behavior and focus interactions work as if actual control
20:07:57 <oedipus> FO: fake focus in background
20:08:23 <oedipus> FO: in future, have UA do surface interaction, if programmatically control focus, can control tab order and interactivity of other controls
20:09:06 <oedipus> FO: biggest hassel - if click on CANVAS element, have to figure out where user clicked; what event to fire (onClick or onFocus) - author needs to do state management not prohibitive, but takes specific wiring
20:09:17 <oedipus> SF: what is in CANVAS spec as regards focus mangagement
20:10:00 <oedipus> FO: nothing specific; very simple to do; no special features required; only thing can't do is put shadow DOM inside CANVAS - could wire up if manipulate DOM  but would be tricky
20:10:11 <oedipus> SF: is it in agreement with what is specified?
20:10:14 <oedipus> FO: yes
20:10:30 <oedipus> FO: once wired up in web browser, can put shadow dom underneath
20:10:33 <oedipus> RS: tabbing?
20:10:43 <oedipus> FO: works in safari, didn't have chance to check with FF
20:11:01 <oedipus> zakim, IPCaller is Stevef
20:11:01 <Zakim> +Stevef; got it
20:11:09 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/01-html-a11y-minutes.html oedipus
20:11:45 <oedipus> RS: can't get it to work in safari
20:11:49 <oedipus> FO: strange....
20:11:57 <oedipus> FO: using safari on windows
20:12:09 <oedipus> FO: we can talk outside of meeting
20:12:11 <oedipus> RS: ok
20:13:05 <oedipus> FO: what you see in CANVAS are 2 checkboxes and a selection rectangle - need API to support that; works like any other control  - should be able to tab to first and second checkbox, use spacebar to toggle checked/not checked
20:13:10 <oedipus> JRG: works for me on the mac
20:13:26 <oedipus> JRG: tabbing to controls with safari; can see shadow DOM checkboxes beneath it
20:13:34 <oedipus> RS: space to select and deselect works fine
20:14:17 <oedipus> FO: biggest part getting state synced up between users of keyboard and users of mouse -- once figure out, though, all the same pattern; hopefully toolkit for canvas will do this on author's behalf
20:14:31 <oedipus> RS: hiding it in ACCESSIBLE won't have impact
20:14:41 <oedipus> FO: once support for ACCESSIBLE node, should work
20:14:47 <oedipus> FO: will try and get it to work
20:14:54 <oedipus> RS: shadow DOM outside canvas
20:15:02 <oedipus> FO: shouldn't have impact on stability of concept
20:15:43 <oedipus> JRG: one potential issue - when inside CANVAS technique for IE to do canvas is a VML plusin -- VML goes inside CANVAS not sure how other content would react to that
20:16:07 <oedipus> FO: using plug-in in IE6, IE7 and IE8 -- side effect of how implemented plug-in -- fixable problem
20:16:46 <oedipus> zakim, ??P4 is Jon_Gunderson
20:16:46 <Zakim> +Jon_Gunderson; got it
20:16:56 <oedipus> JRG: running snow leopard?
20:17:09 <oedipus> JRG: will try on windows, too
20:17:25 <oedipus> s/leopard?/leopard, latest version/
20:17:55 <oedipus> RS: have to play around with it -- if put inside CANVAS spacebar no longer works
20:18:10 <oedipus> FO: works fine with me in snow leopard -- happy to debug after call
20:18:15 <oedipus> RS: great progress, thanks Frank
20:18:37 <oedipus> JRG: works with FF on mac, too
20:18:49 <oedipus> RS: tabbed to it and didn't see any visual focus
20:18:56 <oedipus> JRG: salmon-colored border
20:19:02 <oedipus> FO: yeah, red border
20:19:36 <oedipus> JRG: saved to desktop and opened it
20:19:43 <oedipus> FO: should work from the get-go
20:19:52 <oedipus> JRG: with FF on mac, tab to it from address bar
20:20:02 <oedipus> RS: running 3.5.7
20:20:16 <oedipus> GJR: current release is 3.6
20:20:33 <oedipus> RS: try to put inside CANVAS to see what is happening
20:20:48 <oedipus> TOPIC: Progress on Chart Example with data table for alternative selection
20:20:53 <oedipus> http://www.w3.org/WAI/PF/HTML/track/actions/16
20:21:06 <oedipus> davidb: http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0145.html
20:21:37 <oedipus> http://devserv.dres.uiuc.edu/ita/jongund/citaweb/test/aria/canvas/canvas1.html
20:22:10 <davidb> oedipus, I saw that email, but haven't gotten to it yet today
20:22:15 <oedipus> JRG: wanted to make sure it is what people are expecting before moring to some place permenant
20:22:52 <oedipus> JRG: status sequences; doesn't work in IE with plugin
20:23:51 <oedipus> JRG: took OurGraph library and added features to it; a lot inaccessible -- sketchbar can be drawn on using mouse; rightClick; if click on bars, brings up tooltip with a click; need to activate focus -- can't i do with aria live regions?
20:24:11 <oedipus> JRG: added content to static chart is one thing, collaborative much more complicated
20:24:26 <oedipus> GJR: couldn't access fallback content with JFW or NVDA and FF 3.6
20:24:50 <oedipus> RS: is TABLE outside of CANVAS
20:24:57 <oedipus> JRG: contained in CANVAS
20:25:09 <oedipus> RS: explains GJR's problem with screen reader access
20:25:23 <oedipus> SF: nothing currently in any implementation exposes anything inside CANVAS
20:25:26 <oedipus> GJR: gotcha
20:25:42 <oedipus> RS: 2 examples to work off of -- need to do something with ContentEditableText
20:25:53 <oedipus> RS: need to do something with focus for magnification?
20:26:00 <oedipus> SF: yes
20:26:11 <oedipus> TOPIC: CANVAS API
20:26:15 <oedipus> RS: anyone implemented
20:26:21 <oedipus> SF: not the one implemented in spec
20:26:34 <oedipus> RS: need UA implementation of fallback in CANVAS
20:26:45 <oedipus> SF: status of work with Alexander Surkov and DavidB?
20:26:51 <oedipus> RS: how to get into IE
20:27:07 <oedipus> FO: adding other features into IE; can't promise work on this for forseeable future
20:27:20 <oedipus> RS: need to see if can get alex to prototype some of this
20:27:36 <oedipus> TOPIC: Define CSS Attributes and meta data for alternative content selection
20:27:40 <oedipus> http://www.w3.org/WAI/PF/HTML/track/actions/17
20:27:44 <oedipus> RS: started that work
20:28:07 <oedipus> RS: raised a few questions
20:28:43 <oedipus> SF: did you see my email about opera implementing IMAP ontop of CANVAS?
20:29:01 <oedipus> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0102.html
20:29:10 <oedipus> RS: collection of links in IMAP?
20:29:17 <oedipus> SF: [breaking up badly]
20:29:48 <oedipus> SF: underlying HTML DOM elements can relate to AREA elements so can add aria ontop of those
20:29:56 <oedipus> RS: role="image" etc.
20:30:06 <oedipus> SF: yeah -- different approach than being discussed here
20:30:08 <oedipus> RS: how?
20:30:37 <oedipus> SF: using existing concept, imagemap in different context; focus management would be done as done in imagemaps
20:30:58 <oedipus> s/concept, imagemap/concepts extant in HTML, imagemep
20:31:47 <oedipus> SF: this example that frank had, would have 2 AREA elements with coordinates; would have programmatic focus supplied by IMAP, so wouldn't have to draw focus rectangle yourself; AREA elements would hve role="checkbox"
20:32:29 <oedipus> SF: works partially now -- what you get, when move focus, will say "button"
20:32:56 <oedipus> SF: if have role="button" will say "button" -- can override native role with ARIA
20:33:08 <oedipus> RS: violating host language strong native semantics
20:33:37 <oedipus> SF: at this piont in time, there aren't strong native semantics in spec; trying to modify them -- wouldn't define A as button; AREA is similar to anchor
20:33:48 <oedipus> RS: draw visual focus on canvas
20:33:58 <oedipus> SF: same way UA does with imagemap; layover
20:34:27 <oedipus> GJR: can understand why investigating because there is pre-existing code that can be reused
20:34:38 <oedipus> RS: show it instead of shadow DOM approach?
20:34:55 <oedipus> SF: their version of shadow DOM is use IMAP with AREA 
20:34:58 <oedipus> RS: within CANVAS?
20:35:07 <oedipus> SF: doesn't have to be; mapped onto imagemap by UA
20:35:26 <oedipus> RS: problem may be that not going to be navigating elements in context of DOM
20:35:35 <oedipus> RS: when get to canvas, what happens?
20:36:00 <oedipus> SF: think of canvas as static image; has areas defined as hotspots, so tab through those as would tab through normal imagemap
20:36:07 <oedipus> RS: between the canvas tags?
20:36:58 <oedipus> SF: presume that if want to, can put AREA elements and IMAP inside CANVAS, but don't need to -- that's tyhe point ; already mapped via mapping for MAP with AREA inside can be anywhere in document as long as coordinates define focus in image
20:37:12 <oedipus> RS: if put at end of document; WCAG says "put in logical order"
20:37:33 <oedipus> SF: ask you to do in manner that AT can interact with it; AREA element can be anywhere
20:37:59 <oedipus> RS: if want to ReadAll, starting above AREA, you're going to end up at end of document
20:38:03 <oedipus> SF: that's how it works today
20:38:13 <oedipus> SF: nothing new -- works on IMAP model
20:38:25 <oedipus> RS: problem not with use of imagemap, but putting outside of CANVAS
20:38:36 <oedipus> SF: what people do with images on imagemaps now
20:38:50 <oedipus> SF: way opera proposal doesn't matter if in CANVAS or outside
20:39:05 <oedipus> RS: if navigating imagemap and there are checkboxes, those would be out-of-context
20:39:27 <oedipus> SF: no, physical focus and information as far as contextual info, AT gets that when has focus on imagemap
20:40:06 <oedipus> RS: no problem with that; what is problem is if context is put in document in document order, mouse interaction not going to be anywhere near a11y for that element; if stick at end of document, have to tab to end then back
20:41:14 <oedipus> SF: way works with imagemap, have image, associate image with imagemap, if have 2 area elements with coordinates on them for that image, when you get to the image, the 2 focusable hotspots are in focus oreder within the imagemap; can go from link to first focusable hotspot, second focusable hotspot, etc. focus order is defined by coordiinates
20:41:19 <Stevef> http://www.paciellogroup.com/blog/misc/canvas-pie/pie.html
20:41:33 <oedipus> RS: write a numerical tab index in there
20:41:40 <oedipus> RS: author would have to do that
20:41:46 <oedipus> SF: not if use imagemap
20:42:12 <oedipus> SF: fine if want to put in canvas;  wanted to stress that opera investigating this, so we should be checking it out too
20:42:25 <oedipus> RS: besides location outside of CANVAS, don't have problem
20:42:37 <oedipus> SF: issue with focus not an issue with imagemap
20:42:42 <oedipus> RS: who is working on it
20:42:58 <oedipus> SF: Opera under chaals -- on HTMTL
20:43:02 <oedipus> RS: will talk to chaals
20:43:26 <oedipus> JRG: by using coordinates of area define interactive places, then use aria markup on AREA element to say what it is?
20:43:30 <oedipus> SF: yes
20:43:48 <oedipus> s/chaals -- on HTMTL/chaals/
20:44:25 <oedipus> SF: in IE when access via MSAA tells you is a button -- by virtue of the ARIA spec, whatever roles are there should override, so ARIA roles should override native roles
20:44:44 <oedipus> RS: AREA flexible enough for all controls?
20:44:53 <oedipus> RS: if want to use standard control inside AREA, can't do that
20:45:12 <oedipus> RS: frank's example with real checkbox
20:45:26 <oedipus> SF: can't do that -- have to define role using ARIA on AREA elements
20:45:49 <oedipus> RS: don't have issue if works; if want to use standard controls, AREA has a lot of limitations
20:45:52 <oedipus> SF: agree
20:46:00 <oedipus> RS: could say is another vehicle if it maps
20:46:27 <oedipus> SF: advantage is that all the focus stuff is done for you using a known construct, the imagemap, so implementation would be trivial, which is a reason for investigation
20:46:36 <oedipus> RS: when get beyond buttons, may not be so simple
20:46:48 <oedipus> SF: then have to have multiple AREA elements
20:46:59 <oedipus> RS: have to find if there is a point of diminishing returns
20:47:11 <oedipus> RS: put tools in hands of authors to do what they need to do
20:47:52 <oedipus> JRG: question for FO -- when manage focus, rely OnFocus on standard form control, then update styling of canvas?
20:48:05 <oedipus> FO: yes, UA handle focus management 
20:48:40 <oedipus> FO: doesn't work if inside CANVAS because treated as fallback content by current UAs; could re-write browser to support ACCESSIBLE tag
20:49:03 <oedipus> FO: if dynamically add it under CANVAS in DOM, but inconsistent from UA to UA
20:49:12 <oedipus> JRG: goal is that all is hidden inside CANVAS element
20:49:29 <oedipus> FO: today's UAs would have to be updated to support interactive elements inside DOM
20:49:38 <oedipus> JRG: could plug-in for IE do this?
20:49:54 <oedipus> FO: clear everything under CANVAS element is bug i filed
20:50:53 <oedipus> JRG: possible implementation problems unless coordination with developers of things for IE; going to have to be cooperation between IE plugin -- people will be manipulating VLM -- possibility of conflicts that will wipe each other out
20:51:33 <oedipus> FO: aware of that problem; where people using VML to add features to IE is a problem for us once we add features to IE natively; native feature conflicting with add on is situation to be avoided
20:52:16 <oedipus> FO: similar to requirement ot update all browsers; all implementations of CANVAS need changes to make this work
20:52:28 <richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0146.html
20:52:48 <oedipus> TOPIC: Access for All
20:53:14 <oedipus> RS: 2 types: accessforall meta-data for user preferences defined in terms of meta-data
20:53:44 <oedipus> RS: tried to simplify set down; chose core data to start with -- does all need to be in here for content, or can we reuse HTML constructs such as "lang"
20:54:10 <oedipus> RS: different content categories for HTML flow (secton, etc.) -- do we need new one for ACCESSIBLE since hidden behind CANVAS
20:54:18 <oedipus> FO: preference is not to add new element
20:54:28 <oedipus> RS: what categories would apply?
20:55:04 <oedipus> RS: flow content (in document flow) -- interactive content (keyboard navigatable within that spece
20:55:13 <oedipus> FO: what problem are you trying to solve with tagging
20:55:34 <oedipus> RS: HTML5 spec defines different types of content for each element, so need to catagorizwe
20:55:50 <oedipus> FO: can be anything - could be interactive, static or dynamically generated
20:55:52 <oedipus> RS: right
20:55:55 <oedipus> FO: good question
20:56:08 <oedipus> RS: a bit of everything
20:56:15 <oedipus> FO: as generic as possible
20:56:31 <oedipus> RS: if people have thoughts on it, please post to list
20:56:44 <oedipus> RS: talked about preceding attributes with aria- 
20:57:16 <oedipus> RS: ARIA part of HTML5 spec links to ARIA spec, so no properties from meta-data about resource capabilites are, not necessarily to driver interoperability
20:57:28 <oedipus> RS: should we procede with afa- for attributes instead of aria-0
20:57:40 <oedipus> s/aria-0/aria-
20:57:58 <oedipus> FO: larger discussion than just CANVAS sub-group
20:58:21 <richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0146.html
20:58:58 <oedipus> TOPIC: CSS media types for tactual and tactile
20:59:06 <oedipus> tactile is defined as "capable of, allows for being touched"; tactual is defined as "arising from or due to touch";
20:59:11 <oedipus> GJR PROPOSAL 1. keep "tactile" as super-set in CSS media groups: [http://www.w3.org/TR/2009/CR-CSS2-20090908/media.html#media-groups]
20:59:16 <oedipus> GJR PROPOSAL 2. add the "tactual" media type (raised line maps, thermoformed objects, etc.) CSS's list of media types: [http://www.w3.org/TR/2009/CR-CSS2-20090908/media.html#media-intro]
20:59:20 <oedipus> that way we only need to ask CSS WG for new media type: tactual
20:59:44 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/01-html-a11y-minutes.html oedipus
20:59:59 <Zakim> -Rich
21:00:00 <Zakim> -Jon_Gunderson
21:00:00 <Zakim> -Gregory_Rosmaita
21:00:02 <Zakim> -Stevef
21:00:03 <Zakim> -[Microsoft]
21:00:04 <Zakim> WAI_PFWG(CANVAS)3:00PM has ended
21:00:05 <Zakim> Attendees were Gregory_Rosmaita, Rich, Frank_Oliver, Stevef, Jon_Gunderson
21:00:17 <oedipus> rrch, minutes ARE world readable
21:00:28 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/01-html-a11y-minutes.html oedipus
21:01:26 <oedipus> zakim, please part
21:01:26 <Zakim> Zakim has left #html-a11y
21:01:41 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/01-html-a11y-minutes.html oedipus
21:02:33 <oedipus> regrets: David_Bolter
21:02:36 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/01-html-a11y-minutes.html oedipus
21:02:58 <oedipus> rrsagent, please part
21:02:58 <RRSAgent> I see no action items