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
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]
20:01:19 [frankolivier]
frankolivier has joined #html-a11y
20:02:38 [Zakim]
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]
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]
20:06:59 [oedipus]
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 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]
20:21:06 [oedipus]
20:21:37 [oedipus]
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]
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]
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]
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]
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]
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]
20:57:58 [oedipus]
FO: larger discussion than just CANVAS sub-group
20:58:21 [richardschwerdtfe]
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: []
20:59:16 [oedipus]
GJR PROPOSAL 2. add the "tactual" media type (raised line maps, thermoformed objects, etc.) CSS's list of media types: []
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 oedipus
20:59:59 [Zakim]
21:00:00 [Zakim]
21:00:00 [Zakim]
21:00:02 [Zakim]
21:00:03 [Zakim]
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 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 oedipus
21:02:33 [oedipus]
regrets: David_Bolter
21:02:36 [RRSAgent]
I have made the request to generate oedipus
21:02:58 [oedipus]
rrsagent, please part
21:02:58 [RRSAgent]
I see no action items