IRC log of html-a11y on 2010-02-01
Timestamps are in UTC.
- 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