See also: IRC log
<trackbot> Date: 08 February 2010
<richardschwerdtfe> meetin: W3C HTML Accessibility Task Force Canvas Accessibility meeting
<scribe> meeting: W3C HTML Accessibility Task Force Canvas Accessibility Meeting
<richardschwerdtfe> Hi Gregory
<richardschwerdtfe> I am on
"conference is restricted at this time..."
<scribe> scribe: Gregory_Rosmaita
<scribe> scribenick: oedipus
RS: have due date of 25 February 2010
RS: DB, you reasearching way of embedding CANVAS inside something else?
DB: not using <accessible> element
RS: explain how - is implementation technique or what?
DB: don't know answer either -
working through; have simple example wrapping CANVAS in DIV,
DIV uses aria, with canvas rendered
... second example: 1 canvas and more than 1 legitimate span over canvas
... quick and dirty solution -- DIV wraps all, inside first DIV are 2 DIVs representing widgets, then CANVAS element
... outer DIV handles focus via activedescendent and handles keyboard and mouse events
... outer DIV "controller" DIV -- does rendering on canvas appropriately with what user is doing - works with mouse, keyboard, and screenreader
... solves screen mag issue on targeting right part of CANVAS
RS: placed DIVs in coordinate
positions underneath canvas - nice
... here is the gotcha - can you do that if using standard form controls
DB: yes, i believe so
RS: so doing same thing without having to do an accessible/shadow dom inside subtree
DB: want to understand if are
gaps and how to fill
... hoping to post to public-canvas-api to see what others think - should i post to public-html?
RS: at high level how work?
DB: haven't thought about caret
... think it is possible to do everything possible
RS: have DOM tree with accessible widgets put in a Z-order that is below canvas; so where inserted? anywhere?
DB: parent node on CANVAS and sibling nodes on CANVAS that have info, but nothing within CANVAS
RS: so you have CANVAS as child of what? top level element?
RS: only need once
RS: if move below in Z-order and hidden by canvas still show in accessibility API
... setting opacity to .01 so essentially aren't drawn but considered to exist
... can give example on top of CANVAS, can mouseclick on them
RS: mouseclicks handled by canvas becaause at top of z-order
DB: in example 2 hits canvas first
RS: MVC wrapping instead of
... fine with me
... here is issue: what happens with fallback content when have wrapper
DB: what is difference between fallback and accessible - fallback when canvas not supported?
... if CANVAS not supported, ignore CANVAS and process child content (basic HTML)
... would have wrapper content as first element, then CANVAS as first child; content wrapped in middle of it?
RS: yes, reasonable
DB: solve scenario through higher level design decisions -- what page starts with, sniff for canvas support, then can pull out at that point
RS: can this be automated?
... Steve has few examples where DOM not wrapped around CANVAS and think FOlliver did one as well
... 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
... when then map accessibleObject coordinates to windows, zoomtext would get both coordinates and go to right place
RS: could add an attribute to
HTML5 -- if browser doesn't support, gets thrown away
... 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"
DB: mark certain DOM elements as only being valid if CANVAS supported
RS: right - if use element, in
dom (though could treat as DIV)
... everything outside fallback content goes away
... reasonable approach?
DB: review - have accessible element that wraps it all; if canvas not supported all goes away
RS: go directly to fallback; flow
content in HTML5
... 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
DB: i'm with you so far
RS: attribute can give positioning too
RS: position elements in DOM relative to CANVAS
RS: is this right approach? don't care if attribute - prefer attribute over element
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
RS: let me give you a11y API
... 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)
... could do just by enabling position elements corresponding to elements in HTML
... does that make sense
... 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
DB: still need contextualizing
code and examples
... doesn't have to work
RS: you were going to try to do
something more complex, right?
... what if build HTML tree that is transparent around CANVAS drawing area to represent working DOM
... update CANVAS accordingly
... one place that has a gotcha is "fallback content"
... what happens if fallback content in middle of CANVAS?
DB: haven't tried it
RS: can you put a TABLE inside of CANVAS to see if ignored?
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
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
... most people will care about "i'm using browser x and it doesn't support canvas"
RS: another approach - what if have accessible DOM at end of document? then overlay there so not visible
JRG: point to accessible DOM using activedescendent or something?
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
JRG: will that keep screen mags synced?
DB: yes, that's the intent; if had that ability today, wouldn't need to move nodes into locations for magnifier
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
DB: makes sense
RS: not much different from what
... this association creates transparent area -- can we use regular DIVs and SPANs to do this or do we need dedicated element
... might make SVG easier too
DB: some area of DOM that gets ignored if CANVAS isn't supported don't care if element or attribute
RS: okay; so do we need a special tag for it?
DB: don't know
RS: this is pretty
straightforward - just add method to DOMAPI for CANVAS that
says "binds this element over" -- could work very well
... doesn't solve caret problem, but need to get SteveF to work on that
... ok; direct overlay of content;
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
... in java seen libraries where objects represent parts of DOM
... have to line up by hand; how we line up could be having a false exposing an attribute
... if can get UA a11y people to bang on this, think we will converge on a solution
RS: have to converge on solution
by next week
... want spec ready text by 25 February 2010
... problem is getting quorum at calls
DB: can you point me to a page or example?
FO: that would very much help with IE team
DB: would pass on to mozilla and
... would also help me know precisely what are latest proposals
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
... not everything can be done with fallback content -- model may not match what is actually there
... if to make directly accessible have to bind accessibleDOM to that area
... if limited by focus management, less of an issue; focus rectangle has to be bound to object somehow
... 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
... 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?
... or just map this DOM to it
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
... would like to hash out with other devs
RS: Frank, your example would work if put to end of doc
FO: what is our strategy for existing UAs that don't have canvas or don't have accessible canvas?
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
FO: could it be put in place where canvas is?
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
FO: sounds like it might work;
need to enumerate 3 scenarios
... 3 categories of browsers: doesn't suport canvas at all, supports canvas today (but not accessible), supports accessible element spoke of today
RS: might have to determine version of UA before calling jscript method
FO: if new UA comes along, may
overtake all UAs; ensure method exists,
... 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
DB: buzzword is "feature detection"
FO: call method, catch exception
... 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
RS: go into tab navigation order
of canvas, right?
... can we get alex to prototype method to insert that content inside of DOM -- has to get into navigation order
DB: place tree into right place in DOM?
DB: mostly care about placing in accessibility tree?
RS: keyboard navigation has to sync with canvas rendering
DB: can't commit alexy
... not enough cycles to do myself
... question for devs is will it affect core, not just a11y
RS: how to prototype?
... prototype or proposal for 2010-02-25
... need proposal
DB: if could work on it on a wiki would help alex and i determine if can do testing implementations
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
... 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
FO: sounds good -- devil's in details, but at high level sounds as if will work
JRG: separate <accessible> element?
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
... has to have special properties set for it
... 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
... only appears in navigation order when associate with <accessible> element
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
... should write down proposal and collaborate on it
JRG: what is problem with restricting element to be inside canvass
RS: if put inside canvas, and UA doesn't support canvas, have fallback content and accessible bindings in document
FO: use jscript to determine if
supported; if not, use fallback content; have to have
and access accessible version
... 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
DB: good point
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
but support for canvas turned off get accessible content
... make rule that accessible content has to be inside canvas -- makes cleaner implementation
RS: have to write all nodes in by hand, though
FO: well... good point
FO: check if canvas element
exists in UA; do specific check for canvas - try calling canvas
method to see if that works
... our problem to solve; can be way that works across all browsers
... standardize what is delivered -- will send a post about this to list
RS: within canvas tag 2 sections -- is that a problem for DB?
<davidb> DB: yep
support, don't need special tag, take and embed in CANVAS -
make transparent or make hidden; if hidden not in navigation
... Frank, you'll investigate how to detect if canvas is supported
FO: good design pattern to change as little as possible
RS: want to discuss alternate content -- anytime this week to reconvene?
FO: best day is thursday or friday
davidb, can you meet again on thursday or friday?
<davidb> since i usually try to keep those meeting-free (for hacking)
RS: afternoon on thursday - 1 pm C.S.T / 11 am P.S.T
<scribe> 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 [recorded in http://www.w3.org/2010/02/08-html-a11y-minutes.html#action01]
<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].
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/wintext/zoomtext/ Succeeded: s/disaction/detection/ Succeeded: s/comite/commit/ Found Scribe: Gregory_Rosmaita Found ScribeNick: oedipus WARNING: Replacing previous Present list. (Old list: Rich, Gregory, David_Bolter) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ Jon_Gunderson Present: Jon_Gunderson David_Bolter Rich Gregory Frank_Oliver WARNING: Replacing previous Regrets list. (Old list: clown) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ Steven_Faulkner Regrets: Steven_Faulkner Agenda: http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0149.html Found Date: 08 Feb 2010 Guessing minutes URL: http://www.w3.org/2010/02/08-html-a11y-minutes.html People with action items: rich WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]