19:58:08 RRSAgent has joined #html-a11y
19:58:08 logging to http://www.w3.org/2010/02/08-html-a11y-irc
19:58:10 RRSAgent, make logs world
19:58:10 Zakim has joined #html-a11y
19:58:12 Zakim, this will be 2119
19:58:12 I do not see a conference matching that name scheduled within the next hour, trackbot
19:58:13 Meeting: HTML Accessibility Task Force Teleconference
19:58:13 Date: 08 February 2010
19:59:01 meetin: W3C HTML Accessibility Task Force Canvas Accessibility meeting
20:00:02 meeting: W3C HTML Accessibility Task Force Canvas Accessibility Meeting
20:00:07 chair: Rich
20:00:15 agenda: http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0149.html
20:00:19 Hi Gregory
20:00:22 I am on
20:01:30 "conference is restricted at this time..."
20:02:21 davidb has joined #html-a11y
20:03:11 scribe: Gregory_Rosmaita
20:03:14 scribenick: oedipus
20:03:32 present: Rich, Gregory, David_Bolter
20:03:46 I have made the request to generate http://www.w3.org/2010/02/08-html-a11y-minutes.html oedipus
20:03:53 regrets: clown
20:04:07 RS: have due date of 25 February 2010
20:05:09 regrets: Steven_Faulkner
20:05:14 I have made the request to generate http://www.w3.org/2010/02/08-html-a11y-minutes.html oedipus
20:05:40 TOPIC: Alternative to David Bolter to discuss possible less complex solution for making canvas directly accessible without a shadow DOM.
20:05:57 RS: DB, you reasearching way of embedding CANVAS inside something else?
20:06:03 DB: not using element
20:06:13 RS: explain how - is implementation technique or what?
20:06:42 DB: don't know answer either - working through; have simple example wrapping CANVAS in DIV, DIV uses aria, with canvas rendered
20:06:59 DB: second example: 1 canvas and more than 1 legitimate span over canvas
20:07:20 DB: quick and dirty solution -- DIV wraps all, inside first DIV are 2 DIVs representing widgets, then CANVAS element
20:07:35 DB: outer DIV handles focus via activedescendent and handles keyboard and mouse events
20:07:59 DB: outer DIV "controller" DIV -- does rendering on canvas appropriately with what user is doing - works with mouse, keyboard, and screenreader
20:08:22 DB: solves screen mag issue on targeting right part of CANVAS
20:08:37 RS: placed DIVs in coordinate positions underneath canvas - nice
20:08:48 RS: here is the gotcha - can you do that if using standard form controls
20:08:52 DB: yes, i believe so
20:09:07 RS: so doing same thing without having to do an accessible/shadow dom inside subtree
20:09:16 DB: want to understand if are gaps and how to fill
20:09:35 DB: hoping to post to public-canvas-api to see what others think - should i post to public-html?
20:09:41 RS: at high level how work?
20:09:58 DB: haven't thought about caret --
20:10:24 DB: think it is possible to do everything possible
20:10:56 RS: have DOM tree with accessible widgets put in a Z-order that is below canvas; so where inserted? anywhere?
20:11:22 DB: parent node on CANVAS and sibling nodes on CANVAS that have info, but nothing within CANVAS
20:11:24 frankolivier has joined #html-a11y
20:11:39 RS: so you have CANVAS as child of what? top level element?
20:11:42 DB: yep
20:11:45 RS: only need once
20:11:47 DB: yep
20:12:02 RS: if move below in Z-order and hidden by canvas still show in accessibility API
20:12:04 DB: yes
20:12:20 DB: setting opacity to .01 so essentially aren't drawn but considered to exist
20:12:32 DB: can give example on top of CANVAS, can mouseclick on them
20:12:51 RS: mouseclicks handled by canvas becaause at top of z-order
20:12:58 DB: in example 2 hits canvas first
20:13:07 RS: MVC wrapping instead of embedding
20:13:12 RS: fine with me
20:13:26 RS: here is issue: what happens with fallback content when have wrapper
20:13:45 DB: what is difference between fallback and accessible - fallback when canvas not supported?
20:13:47 RS: yes
20:14:09 RS: if CANVAS not supported, ignore CANVAS and process child content (basic HTML)
20:14:32 RS: would have wrapper content as first element, then CANVAS as first child; content wrapped in middle of it?
20:14:40 DB: can we assume javascript is supported?
20:14:45 RS: yes, reasonable
20:15:14 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 RS: can this be automated?
20:15:23 DB: hmmm.....
20:15:46 DB: Steve has few examples where DOM not wrapped around CANVAS and think FOlliver did one as well
20:16:32 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 DB: when then map accessibleObject coordinates to windows, wintext would get both coordinates and go to right place
20:17:04 s/wintext/zoomtext
20:17:21 RS: could add an attribute to HTML5 -- if browser doesn't support, gets thrown away
20:18:05 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 DB: mark certain DOM elements as only being valid if CANVAS supported
20:18:31 RS: right - if use element, in dom (though could treat as DIV)
20:18:43 RS: everything outside fallback content goes away
20:18:48 RS: reasonable approach?
20:19:13 DB: review - have accessible element that wraps it all; if canvas not supported all goes away
20:19:16 FO: ok
20:19:29 RS: go directly to fallback; flow content in HTML5
20:20:01 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 DB: i'm with you so far
20:20:06 jongunderson has joined #html-a11y
20:20:13 zakim, who is here?
20:20:13 sorry, oedipus, I don't know what conference this is
20:20:14 On IRC I see jongunderson, frankolivier, davidb, Zakim, RRSAgent, richardschwerdtfe, oedipus, MichaelC, trackbot
20:20:25 I have made the request to generate http://www.w3.org/2010/02/08-html-a11y-minutes.html oedipus
20:20:31 RS: attribute can give positioning too
20:20:33 DB: how
20:20:41 RS: position elements in DOM relative to CANVAS
20:20:43 DB: sure
20:21:09 RS: is this right approach? don't care if attribute - prefer attribute over element
20:21:36 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 RS: let me give you a11y API version
20:22:33 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 RS: could do just by enabling position elements corresponding to elements in HTML
20:22:58 RS: does that make sense
20:23:45 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 DB: still need contextualizing code and examples
20:24:19 DB: doesn't have to work
20:24:34 RS: you were going to try to do something more complex, right?
20:24:39 present: Jon_Gunderson
20:24:44 I have made the request to generate http://www.w3.org/2010/02/08-html-a11y-minutes.html oedipus
20:25:13 present+ David_Bolter,Rich,Gregory
20:25:17 I have made the request to generate http://www.w3.org/2010/02/08-html-a11y-minutes.html oedipus
20:25:38 RS: what if build HTML tree that is transparent around CANVAS drawing area to represent working DOM
20:25:43 RS: update CANVAS accordingly
20:25:53 RS: one place that has a gotcha is "fallback content"
20:26:03 RS: what happens if fallback content in middle of CANVAS?
20:26:07 DB: haven't tried it
20:26:28 RS: can you put a TABLE inside of CANVAS to see if ignored?
20:26:29 DB: yes
20:27:23 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 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 JRG: most people will care about "i'm using browser x and it doesn't support canvas"
20:28:48 RS: another approach - what if have accessible DOM at end of document? then overlay there so not visible
20:28:51 DB: yeah
20:29:06 JRG: point to accessible DOM using activedescendent or something?
20:30:00 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 JRG: will that keep screen mags synced?
20:30:28 DB: yes, that's the intent; if had that ability today, wouldn't need to move nodes into locations for magnifier
20:31:22 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 DB: makes sense
20:31:47 RS: not much different from what have now
20:32:12 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 RS: might make SVG easier too
20:32:48 DB: some area of DOM that gets ignored if CANVAS isn't supported don't care if element or attribute
20:32:58 RS: okay; so do we need a special tag for it?
20:33:01 DB: don't know
20:33:31 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 RS: doesn't solve caret problem, but need to get SteveF to work on that
20:33:57 RS: ok; direct overlay of content;
20:34:32 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 DB: in java seen libraries where objects represent parts of DOM
20:35:22 DB: have to line up by hand; how we line up could be having a false exposing an attribute
20:35:41 DB: if can get UA a11y people to bang on this, think we will converge on a solution
20:35:48 RS: have to converge on solution by next week
20:35:59 RS: want spec ready text by 25 February 2010
20:36:06 RS: problem is getting quorum at calls
20:36:45 DB: can you point me to a page or example?
20:36:53 FO: that would very much help with IE team
20:36:59 DB: would pass on to mozilla and apple
20:37:12 DB: would also help me know precisely what are latest proposals
20:37:39 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 RS: not everything can be done with fallback content -- model may not match what is actually there
20:38:10 RS: if to make directly accessible have to bind accessibleDOM to that area
20:38:37 RS: if limited by focus management, less of an issue; focus rectangle has to be bound to object somehow
20:39:16 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 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 RS: or just map this DOM to it
20:40:42 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 DB: would like to hash out with other devs
20:41:03 RS: Frank, your example would work if put to end of doc
20:41:19 FO: what is our strategy for existing UAs that don't have canvas or don't have accessible canvas?
20:42:14 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 FO: could it be put in place where canvas is?
20:42:55 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 FO: sounds like it might work; need to enumerate 3 scenarios
20:43:49 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 RS: might have to determine version of UA before calling jscript method
20:44:30 FO: if new UA comes along, may overtake all UAs; ensure method exists,
20:45:20 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 DB: buzzword is "feature disaction"
20:45:38 s/disaction/detection
20:45:42 FO: call method, catch exception another route
20:46:29 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 RS: go into tab navigation order of canvas, right?
20:47:15 RS: can we get alex to prototype method to insert that content inside of DOM -- has to get into navigation order
20:47:23 DB: place tree into right place in DOM?
20:47:24 RS: right
20:47:34 DB: mostly care about placing in accessibility tree?
20:47:44 RS: keyboard navigation has to sync with canvas rendering
20:47:53 DB: can't comite alexy
20:48:01 s/comite/commit
20:48:14 DB: not enough cycles to do myself
20:48:40 DB: question for devs is will it affect core, not just a11y
20:48:49 RS: how to prototype?
20:48:59 RS: prototype or proposal for 2010-02-25
20:49:02 RS: need proposal
20:49:26 DB: if could work on it on a wiki would help alex and i determine if can do testing implementations
20:49:58 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 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 FO: sounds good -- devil's in details, but at high level sounds as if will work
20:51:01 JRG: separate element?
20:51:49 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 RS: has to have special properties set for it
20:52:40 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 RS: only appears in navigation order when associate with element
20:54:01 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 FO: should write down proposal and collaborate on it
20:54:34 JRG: what is problem with restricting element to be inside canvass
20:54:54 RS: if put inside canvas, and UA doesn't support canvas, have fallback content and accessible bindings in document
20:55:41 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 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 DB: good point
20:57:15 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 FO: make rule that accessible content has to be inside canvas -- makes cleaner implementation
20:57:40 RS: have to write all nodes in by hand, though
20:57:51 FO: well... good point
20:58:39 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 RS: 2 diff kinds of content; determine if supports canvas and javascript
20:59:05 FO: correct
20:59:09 RS: techniques?
20:59:44 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 FO: our problem to solve; can be way that works across all browsers
21:00:15 FO: standardize what is delivered -- will send a post about this to list
21:00:33 RS: within canvas tag 2 sections -- is that a problem for DB?
21:01:16 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 FO: for canvas to be useful, have to have javascript, so fair assumption
21:01:41 DB: yep
21:01:58 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 RS: Frank, you'll investigate how to detect if canvas is supported
21:02:42 FO: good design pattern to change as little as possible
21:03:06 RS: want to discuss alternate content -- anytime this week to reconvene?
21:03:15 FO: best day is thursday or friday
21:03:36 davidb, can you meet again on thursday or friday?
21:03:57 ok
21:04:03 probably
21:04:16 since i usually try to keep those meeting-free (for hacking)
21:04:21 RS: afternoon on thursday - 1 pm C.S.T / 11 am P.S.T
21:05:34 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 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 zakim, please part
21:05:53 Zakim has left #html-a11y
21:05:59 I have made the request to generate http://www.w3.org/2010/02/08-html-a11y-minutes.html oedipus
21:07:09 present+ Frank_Oliver
21:07:11 I have made the request to generate http://www.w3.org/2010/02/08-html-a11y-minutes.html oedipus
21:13:23 I have made the request to generate http://www.w3.org/2010/02/08-html-a11y-minutes.html oedipus
21:13:36 rrsagent, please part
21:13:36 I see 1 open action item saved in http://www.w3.org/2010/02/08-html-a11y-actions.rdf :
21:13:36 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 recorded in http://www.w3.org/2010/02/08-html-a11y-irc#T21-05-34