minutes: Canvas sub-group HTML A11y Task Force telecon, 2010-02-08 [draft]

aloha!

minutes from the 8 February 2010 Canvas Sub-group of the HTML 
Accessibility Task Force are available as hypertext at:

http://www.w3.org/2010/02/08-html-a11y-minutes.html

as an IRC log at:

http://www.w3.org/2010/02/08-html-a11y-irc

and as plain text following my signature.  as usual, please log any 
comments, corrections, mis-attributions, and clarifications by 
replying-to this announcement on-list.

note that Rich is attempting to schedule a supplemental CANVAS subgroup
meeting for 2pm E.S.T/1pm C.S.T./11am P.S.T./1900h UTC on THURSDAY, 
10 FEBRUARY 2010 -- please mark your schedule and keep an eye, ear, 
fingertip or whatever "open" for Rich's announcement of a supplemental 
canvas call THIS WEEK in furtherance of meeting the 25 February 2010
deadline for our outline proposal to the HTML WG

the supplemental meeting is the topic of the sole action item assigned
at the 2010-02-08 teleconference:

   * ACTION-18: Rich - set up call for canvas accessibility meeting on
   alternates at 2pm E.S.T/1 pm C.S.T/11am P.S.T on 2010-02-10
   * http://www.w3.org/WAI/PF/HTML/track/actions/18

thank you, gregory.

     _________________________________________________________________
                                   - DRAFT -

                 HTML Accessibility Task Force Teleconference

08 Feb 2010

Agenda:
http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0149.html



   See also: IRC log [http://www.w3.org/2010/02/08-html-a11y-irc]

Attendees

   Present
          Jon_Gunderson, David_Bolter, Rich, Gregory, Frank_Oliver

   Regrets
          Steven_Faulkner

   Chair
          Rich

   Scribe
          Gregory_Rosmaita

Contents

     * Topics
         1. Alternative to <accessible> David Bolter to discuss possible
            less complex solution for making canvas directly accessible
            without a shadow DOM.
     * Summary of Action Items
     _________________________________________________________________

   <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

Alternative to <accessible> David Bolter to discuss possible less complex
solution for making canvas directly accessible without a shadow DOM.

   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?

   DB: yep

   RS: only need once

   DB: yep

   RS: if move below in Z-order and hidden by canvas still show in
   accessibility API

   DB: yes
   ... 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 embedding
   ... 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?

   RS: yes
   ... 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?

   DB: can we assume javascript is supported?

   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?

   DB: hmmm.....
   ... 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

   FO: ok

   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

   DB: how

   RS: position elements in DOM relative to CANVAS

   DB: sure

   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 version
   ... 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?

   DB: yes

   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

   DB: yeah

   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 have now
   ... 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 apple
   ... 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 another route
   ... 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?

   RS: right

   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 navigation order
   ... 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 javascript to perform CANVAS; if have canvas,
   can kill fallback 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 canvas, don't have javascript, get fallback; if have
   jscript but support for canvas turned off get accessible content
   fallback discarded
   ... 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
   ... 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

   RS: 2 diff kinds of content; determine if supports canvas and
   javascript

   FO: correct

   RS: techniques?

   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?

   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

   FO: for canvas to be useful, have to have javascript, so fair
   assumption

   <davidb> DB: yep

   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
   ... 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?

   ok

   <davidb> probably

   <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].

Summary of Action Items

   [NEW] 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 on 2010-02-10
   http://www.w3.org/WAI/PF/HTML/track/actions/18
   
   [End of minutes]
     _________________________________________________________________

Received on Monday, 8 February 2010 21:21:48 UTC