IRC log of html-a11y on 2010-02-08

Timestamps are in UTC.

19:58:08 [RRSAgent]
RRSAgent has joined #html-a11y
19:58:08 [RRSAgent]
logging to
19:58:10 [trackbot]
RRSAgent, make logs world
19:58:10 [Zakim]
Zakim has joined #html-a11y
19:58:12 [trackbot]
Zakim, this will be 2119
19:58:12 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
19:58:13 [trackbot]
Meeting: HTML Accessibility Task Force Teleconference
19:58:13 [trackbot]
Date: 08 February 2010
19:59:01 [richardschwerdtfe]
meetin: W3C HTML Accessibility Task Force Canvas Accessibility meeting
20:00:02 [oedipus]
meeting: W3C HTML Accessibility Task Force Canvas Accessibility Meeting
20:00:07 [oedipus]
chair: Rich
20:00:15 [oedipus]
20:00:19 [richardschwerdtfe]
Hi Gregory
20:00:22 [richardschwerdtfe]
I am on
20:01:30 [oedipus]
"conference is restricted at this time..."
20:02:21 [davidb]
davidb has joined #html-a11y
20:03:11 [oedipus]
scribe: Gregory_Rosmaita
20:03:14 [oedipus]
scribenick: oedipus
20:03:32 [oedipus]
present: Rich, Gregory, David_Bolter
20:03:46 [RRSAgent]
I have made the request to generate oedipus
20:03:53 [oedipus]
regrets: clown
20:04:07 [oedipus]
RS: have due date of 25 February 2010
20:05:09 [oedipus]
regrets: Steven_Faulkner
20:05:14 [RRSAgent]
I have made the request to generate oedipus
20:05:40 [oedipus]
TOPIC: Alternative to <accessible> David Bolter to discuss possible less complex solution for making canvas directly accessible without a shadow DOM.
20:05:57 [oedipus]
RS: DB, you reasearching way of embedding CANVAS inside something else?
20:06:03 [oedipus]
DB: not using <accessible> element
20:06:13 [oedipus]
RS: explain how - is implementation technique or what?
20:06:42 [oedipus]
DB: don't know answer either - working through; have simple example wrapping CANVAS in DIV, DIV uses aria, with canvas rendered
20:06:59 [oedipus]
DB: second example: 1 canvas and more than 1 legitimate span over canvas
20:07:20 [oedipus]
DB: quick and dirty solution -- DIV wraps all, inside first DIV are 2 DIVs representing widgets, then CANVAS element
20:07:35 [oedipus]
DB: outer DIV handles focus via activedescendent and handles keyboard and mouse events
20:07:59 [oedipus]
DB: outer DIV "controller" DIV -- does rendering on canvas appropriately with what user is doing - works with mouse, keyboard, and screenreader
20:08:22 [oedipus]
DB: solves screen mag issue on targeting right part of CANVAS
20:08:37 [oedipus]
RS: placed DIVs in coordinate positions underneath canvas - nice
20:08:48 [oedipus]
RS: here is the gotcha - can you do that if using standard form controls
20:08:52 [oedipus]
DB: yes, i believe so
20:09:07 [oedipus]
RS: so doing same thing without having to do an accessible/shadow dom inside subtree
20:09:16 [oedipus]
DB: want to understand if are gaps and how to fill
20:09:35 [oedipus]
DB: hoping to post to public-canvas-api to see what others think - should i post to public-html?
20:09:41 [oedipus]
RS: at high level how work?
20:09:58 [oedipus]
DB: haven't thought about caret --
20:10:24 [oedipus]
DB: think it is possible to do everything possible
20:10:56 [oedipus]
RS: have DOM tree with accessible widgets put in a Z-order that is below canvas; so where inserted? anywhere?
20:11:22 [oedipus]
DB: parent node on CANVAS and sibling nodes on CANVAS that have info, but nothing within CANVAS
20:11:24 [frankolivier]
frankolivier has joined #html-a11y
20:11:39 [oedipus]
RS: so you have CANVAS as child of what? top level element?
20:11:42 [oedipus]
DB: yep
20:11:45 [oedipus]
RS: only need once
20:11:47 [oedipus]
DB: yep
20:12:02 [oedipus]
RS: if move below in Z-order and hidden by canvas still show in accessibility API
20:12:04 [oedipus]
DB: yes
20:12:20 [oedipus]
DB: setting opacity to .01 so essentially aren't drawn but considered to exist
20:12:32 [oedipus]
DB: can give example on top of CANVAS, can mouseclick on them
20:12:51 [oedipus]
RS: mouseclicks handled by canvas becaause at top of z-order
20:12:58 [oedipus]
DB: in example 2 hits canvas first
20:13:07 [oedipus]
RS: MVC wrapping instead of embedding
20:13:12 [oedipus]
RS: fine with me
20:13:26 [oedipus]
RS: here is issue: what happens with fallback content when have wrapper
20:13:45 [oedipus]
DB: what is difference between fallback and accessible - fallback when canvas not supported?
20:13:47 [oedipus]
RS: yes
20:14:09 [oedipus]
RS: if CANVAS not supported, ignore CANVAS and process child content (basic HTML)
20:14:32 [oedipus]
RS: would have wrapper content as first element, then CANVAS as first child; content wrapped in middle of it?
20:14:40 [oedipus]
DB: can we assume javascript is supported?
20:14:45 [oedipus]
RS: yes, reasonable
20:15:14 [oedipus]
DB: solve scenario through higher level design decisions -- what page starts with, sniff for canvas support, then can pull out at that point
20:15:20 [oedipus]
RS: can this be automated?
20:15:23 [oedipus]
DB: hmmm.....
20:15:46 [oedipus]
DB: Steve has few examples where DOM not wrapped around CANVAS and think FOlliver did one as well
20:16:32 [oedipus]
DB: as coding, one thing i thought might be handy is if add ARIA giving position of element (aria-x-coordinate aria-y-coordinate) might be elegant way to relocate things in a11y tree ONLY
20:16:54 [oedipus]
DB: when then map accessibleObject coordinates to windows, wintext would get both coordinates and go to right place
20:17:04 [davidb]
20:17:21 [oedipus]
RS: could add an attribute to HTML5 -- if browser doesn't support, gets thrown away
20:18:05 [oedipus]
RS: Canvas heavy-weight; if we introduce attribute in HTML5 that says "this is a11y mapping for canvas; in UAs that don't support CANVAS this goes away and render fallback content"
20:18:17 [oedipus]
DB: mark certain DOM elements as only being valid if CANVAS supported
20:18:31 [oedipus]
RS: right - if use element, in dom (though could treat as DIV)
20:18:43 [oedipus]
RS: everything outside fallback content goes away
20:18:48 [oedipus]
RS: reasonable approach?
20:19:13 [oedipus]
DB: review - have accessible element that wraps it all; if canvas not supported all goes away
20:19:16 [oedipus]
FO: ok
20:19:29 [oedipus]
RS: go directly to fallback; flow content in HTML5
20:20:01 [oedipus]
RS: wouldn't want to make author mark every element -- fallback content takes precedent over what is there because canvas not supported -- special form of DIV
20:20:06 [oedipus]
DB: i'm with you so far
20:20:06 [jongunderson]
jongunderson has joined #html-a11y
20:20:13 [oedipus]
zakim, who is here?
20:20:13 [Zakim]
sorry, oedipus, I don't know what conference this is
20:20:14 [Zakim]
On IRC I see jongunderson, frankolivier, davidb, Zakim, RRSAgent, richardschwerdtfe, oedipus, MichaelC, trackbot
20:20:25 [RRSAgent]
I have made the request to generate oedipus
20:20:31 [oedipus]
RS: attribute can give positioning too
20:20:33 [oedipus]
DB: how
20:20:41 [oedipus]
RS: position elements in DOM relative to CANVAS
20:20:43 [oedipus]
DB: sure
20:21:09 [oedipus]
RS: is this right approach? don't care if attribute - prefer attribute over element
20:21:36 [oedipus]
DB: i have trouble knowing if on same page -- need to write up and read so i know what you are asking; not sure how position issue comes up
20:21:46 [oedipus]
RS: let me give you a11y API version
20:22:33 [oedipus]
RS: wrapping element and HTML element that corresponds to element in page: need to drive (a) focus mangagement for magnifier, and (b) braille devices where positioning may be important in grid view (review mode coordinates)
20:22:48 [oedipus]
RS: could do just by enabling position elements corresponding to elements in HTML
20:22:58 [oedipus]
RS: does that make sense
20:23:45 [oedipus]
RS: take "toolbar" -- can use HTML toolbar (don't know how coordinates would line up) -- if toolbar entries for each (role="button" in tab list) can give position to each one, so that when receive focus or are rendered in accessible view correctly
20:23:55 [oedipus]
DB: still need contextualizing code and examples
20:24:19 [oedipus]
DB: doesn't have to work
20:24:34 [oedipus]
RS: you were going to try to do something more complex, right?
20:24:39 [oedipus]
present: Jon_Gunderson
20:24:44 [RRSAgent]
I have made the request to generate oedipus
20:25:13 [oedipus]
present+ David_Bolter,Rich,Gregory
20:25:17 [RRSAgent]
I have made the request to generate oedipus
20:25:38 [oedipus]
RS: what if build HTML tree that is transparent around CANVAS drawing area to represent working DOM
20:25:43 [oedipus]
RS: update CANVAS accordingly
20:25:53 [oedipus]
RS: one place that has a gotcha is "fallback content"
20:26:03 [oedipus]
RS: what happens if fallback content in middle of CANVAS?
20:26:07 [oedipus]
DB: haven't tried it
20:26:28 [oedipus]
RS: can you put a TABLE inside of CANVAS to see if ignored?
20:26:29 [oedipus]
DB: yes
20:27:23 [oedipus]
RS: what happens when UA doesn't support canvas at all because too complex overhead for UA; go back to fallback content - fallback content in middle of CANVAS tag embedded inside accessible collection of elements; what should have been hidden is now in middle of a11ytree or html model
20:28:06 [oedipus]
JRG: from practical standpoint 2 issues: 1) most people will say "go get a browser with canvas"; 2) for IE users, there is a plug-in that turns canvas into VML and VML put inside canvas
20:28:24 [oedipus]
JRG: most people will care about "i'm using browser x and it doesn't support canvas"
20:28:48 [oedipus]
RS: another approach - what if have accessible DOM at end of document? then overlay there so not visible
20:28:51 [oedipus]
DB: yeah
20:29:06 [oedipus]
JRG: point to accessible DOM using activedescendent or something?
20:30:00 [oedipus]
DB: probably 50 permutations we could try; decide whether focus goes to Canvas or some other node, if other node, make sure in right place on screen for magnification; put in order you want; design decision - what one wants to do - have handlers on Canvas or another node
20:30:10 [oedipus]
JRG: will that keep screen mags synced?
20:30:28 [oedipus]
DB: yes, that's the intent; if had that ability today, wouldn't need to move nodes into locations for magnifier
20:31:22 [oedipus]
RS: so what we would do to solve magnification problem with CANVAS and fallback content -- add method to CANVAS that associates accessibleDOMTree at end with CANVAS, if CANVAS not supported, going to ignore the whole thing altogether
20:31:29 [oedipus]
DB: makes sense
20:31:47 [oedipus]
RS: not much different from what have now
20:32:12 [oedipus]
RS: this association creates transparent area -- can we use regular DIVs and SPANs to do this or do we need dedicated element
20:32:19 [oedipus]
RS: might make SVG easier too
20:32:48 [oedipus]
DB: some area of DOM that gets ignored if CANVAS isn't supported don't care if element or attribute
20:32:58 [oedipus]
RS: okay; so do we need a special tag for it?
20:33:01 [oedipus]
DB: don't know
20:33:31 [oedipus]
RS: this is pretty straightforward - just add method to DOMAPI for CANVAS that says "binds this element over" -- could work very well
20:33:44 [oedipus]
RS: doesn't solve caret problem, but need to get SteveF to work on that
20:33:57 [oedipus]
RS: ok; direct overlay of content;
20:34:32 [oedipus]
DB: 1 thing to consider is accessibleDOM - -each element in there has to be lined up in partner with counterpart in CANVAS; have to be more specific than overlays canvas
20:34:54 [oedipus]
DB: in java seen libraries where objects represent parts of DOM
20:35:22 [oedipus]
DB: have to line up by hand; how we line up could be having a false exposing an attribute
20:35:41 [oedipus]
DB: if can get UA a11y people to bang on this, think we will converge on a solution
20:35:48 [oedipus]
RS: have to converge on solution by next week
20:35:59 [oedipus]
RS: want spec ready text by 25 February 2010
20:36:06 [oedipus]
RS: problem is getting quorum at calls
20:36:45 [oedipus]
DB: can you point me to a page or example?
20:36:53 [oedipus]
FO: that would very much help with IE team
20:36:59 [oedipus]
DB: would pass on to mozilla and apple
20:37:12 [oedipus]
DB: would also help me know precisely what are latest proposals
20:37:39 [oedipus]
RS: sounds to me that having accessibleDOM inside CANVAS conflicts with fallback content; my take is no matter what we do, it will be a roadblock
20:38:00 [oedipus]
RS: not everything can be done with fallback content -- model may not match what is actually there
20:38:10 [oedipus]
RS: if to make directly accessible have to bind accessibleDOM to that area
20:38:37 [oedipus]
RS: if limited by focus management, less of an issue; focus rectangle has to be bound to object somehow
20:39:16 [oedipus]
RS: if want to go in and lay out elements in a pixel-by-pixel view might be a bit more challanging, but if going through accessibilityAPI using logical structure, should be ok
20:39:56 [oedipus]
RS: what we are proposing is: have CANVAS, can have DOM that resides at end of document; write API to associate CANVAS element with AccessibleDOM so has certain characterstics -- transparency?
20:40:05 [oedipus]
RS: or just map this DOM to it
20:40:42 [oedipus]
DB: don't know offhand; if talking about new element, UA can decide not to render it -- if all that matters is logical structure, then do away with everything else and opacity not relevant
20:40:53 [oedipus]
DB: would like to hash out with other devs
20:41:03 [oedipus]
RS: Frank, your example would work if put to end of doc
20:41:19 [oedipus]
FO: what is our strategy for existing UAs that don't have canvas or don't have accessible canvas?
20:42:14 [oedipus]
RS: have accessible element at end of document that has characteristics in that is transparent; add method to canvas to associate a11yDOM with canvas element; if canvas not supported in UA, UA will ignore whole thing and go directly to fallback and one would nevewr see accessibleDOm at end
20:42:25 [oedipus]
FO: could it be put in place where canvas is?
20:42:55 [oedipus]
RS: map to accessible API; if UA supports canvas, goes right into accessible element for tabbing; if doesn't support, just take fallback content full stop
20:43:09 [oedipus]
FO: sounds like it might work; need to enumerate 3 scenarios
20:43:49 [oedipus]
FO: 3 categories of browsers: doesn't suport canvas at all, supports canvas today (but not accessible), supports accessible element spoke of today
20:44:06 [oedipus]
RS: might have to determine version of UA before calling jscript method
20:44:30 [oedipus]
FO: if new UA comes along, may overtake all UAs; ensure method exists,
20:45:20 [oedipus]
FO: if ensure method exists, when do "check for browser X" if find throw away; don't want to check for UA or UA version, but if method exists; if method exists, do it; if not, fallback
20:45:28 [oedipus]
DB: buzzword is "feature disaction"
20:45:38 [davidb]
20:45:42 [oedipus]
FO: call method, catch exception another route
20:46:29 [oedipus]
FO: have to test samples in 3 different browsers corresponding to categories outlined above: 1) no support for canvas; 2) support for canvas as is today; 3) support for canvas and accessible element
20:46:39 [oedipus]
RS: go into tab navigation order of canvas, right?
20:47:15 [oedipus]
RS: can we get alex to prototype method to insert that content inside of DOM -- has to get into navigation order
20:47:23 [oedipus]
DB: place tree into right place in DOM?
20:47:24 [oedipus]
RS: right
20:47:34 [oedipus]
DB: mostly care about placing in accessibility tree?
20:47:44 [oedipus]
RS: keyboard navigation has to sync with canvas rendering
20:47:53 [oedipus]
DB: can't comite alexy
20:48:01 [oedipus]
20:48:14 [oedipus]
DB: not enough cycles to do myself
20:48:40 [oedipus]
DB: question for devs is will it affect core, not just a11y
20:48:49 [oedipus]
RS: how to prototype?
20:48:59 [oedipus]
RS: prototype or proposal for 2010-02-25
20:49:02 [oedipus]
RS: need proposal
20:49:26 [oedipus]
DB: if could work on it on a wiki would help alex and i determine if can do testing implementations
20:49:58 [oedipus]
RS: will work with laura to get this up on wiki -- Frank does this make sense - if don't support canvas, then this will not impact you at all -- fallback content just goes thorugh
20:50:35 [oedipus]
RS: if set method for binding, don't need to worry; if goes through, would go into the document navigation order in DOM and be mapped to a11y tree
20:50:52 [oedipus]
FO: sounds good -- devil's in details, but at high level sounds as if will work
20:51:01 [oedipus]
JRG: separate <accessible> element?
20:51:49 [oedipus]
RS: can do with DIV and stylesheet to say this is transparent (technique); don't need new element if add new DOM call to CANVAS area; problem is transparency - if at end of document, wouldn't it be in navigation order
20:52:01 [oedipus]
RS: has to have special properties set for it
20:52:40 [oedipus]
RS: can use DIV and style as transparent, put at end of document; if just do that, what is in DIV at end would be in navigation order which would lead to tabbing through invisible items
20:52:59 [oedipus]
RS: only appears in navigation order when associate with <accessible> element
20:54:01 [oedipus]
FO: natural tab order solution - scenario where need double focus; could have UA change tab order by associating with CANVAS element; numerous approaches, but pros and cons to all of them
20:54:11 [oedipus]
FO: should write down proposal and collaborate on it
20:54:34 [oedipus]
JRG: what is problem with restricting element to be inside canvass
20:54:54 [oedipus]
RS: if put inside canvas, and UA doesn't support canvas, have fallback content and accessible bindings in document
20:55:41 [oedipus]
FO: use jscript to determine if supported; if not, use fallback content; have to have javascript to perform CANVAS; if have canvas, can kill fallback and access accessible version
20:56:09 [oedipus]
FO: more i think about this, want to keep accessible content with canvas; if using library to add canvas UIs to document, can't drop in DIVs from other pages on page
20:56:12 [oedipus]
DB: good point
20:57:15 [oedipus]
FO: no situation where the accessible information and fallback text collide; can be fixed in all cases because jscript running on page; if don't have canvas, don't have javascript, get fallback; if have jscript but support for canvas turned off get accessible content fallback discarded
20:57:32 [oedipus]
FO: make rule that accessible content has to be inside canvas -- makes cleaner implementation
20:57:40 [oedipus]
RS: have to write all nodes in by hand, though
20:57:51 [oedipus]
FO: well... good point
20:58:39 [oedipus]
FO: could have 2 DIVs inside canvas - 1 fallback 1 accessible content - have 1 set to display:none - switch in accordance with javascript sniffing to ascertain if javascript supported by UA
20:59:02 [oedipus]
RS: 2 diff kinds of content; determine if supports canvas and javascript
20:59:05 [oedipus]
FO: correct
20:59:09 [oedipus]
RS: techniques?
20:59:44 [oedipus]
FO: check if canvas element exists in UA; do specific check for canvas - try calling canvas method to see if that works
21:00:00 [oedipus]
FO: our problem to solve; can be way that works across all browsers
21:00:15 [oedipus]
FO: standardize what is delivered -- will send a post about this to list
21:00:33 [oedipus]
RS: within canvas tag 2 sections -- is that a problem for DB?
21:01:16 [oedipus]
DB: just locating different spot; what FO describing is common design pattern for web developers; progressive enhancement; can move trees around turn on and off, so a lot solveable when assume have javascript
21:01:29 [oedipus]
FO: for canvas to be useful, have to have javascript, so fair assumption
21:01:41 [davidb]
DB: yep
21:01:58 [oedipus]
RS: assuming have javascript support, don't need special tag, take and embed in CANVAS - make transparent or make hidden; if hidden not in navigation order
21:02:30 [oedipus]
RS: Frank, you'll investigate how to detect if canvas is supported
21:02:42 [oedipus]
FO: good design pattern to change as little as possible
21:03:06 [oedipus]
RS: want to discuss alternate content -- anytime this week to reconvene?
21:03:15 [oedipus]
FO: best day is thursday or friday
21:03:36 [oedipus]
davidb, can you meet again on thursday or friday?
21:03:57 [oedipus]
21:04:03 [davidb]
21:04:16 [davidb]
since i usually try to keep those meeting-free (for hacking)
21:04:21 [oedipus]
RS: afternoon on thursday - 1 pm C.S.T / 11 am P.S.T
21:05:34 [oedipus]
ACTION: Rich - set up call for canvas accessibility meeting on alternates at 2pm E.S.T/1 pm C.S.T/11am P.S.T
21:05:34 [trackbot]
Created ACTION-18 - - set up call for canvas accessibility meeting on alternates at 2pm E.S.T/1 pm C.S.T/11am P.S.T [on Richard Schwerdtfeger - due 2010-02-15].
21:05:53 [oedipus]
zakim, please part
21:05:53 [Zakim]
Zakim has left #html-a11y
21:05:59 [RRSAgent]
I have made the request to generate oedipus
21:07:09 [oedipus]
present+ Frank_Oliver
21:07:11 [RRSAgent]
I have made the request to generate oedipus
21:13:23 [RRSAgent]
I have made the request to generate oedipus
21:13:36 [oedipus]
rrsagent, please part
21:13:36 [RRSAgent]
I see 1 open action item saved in :
21:13:36 [RRSAgent]
ACTION: Rich - set up call for canvas accessibility meeting on alternates at 2pm E.S.T/1 pm C.S.T/11am P.S.T [1]
21:13:36 [RRSAgent]
recorded in