HTML Accessibility Task Force Teleconference -- 08 Feb 2010

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

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

- DRAFT -

HTML Accessibility Task Force Teleconference

08 Feb 2010

Attendees

Contents

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

Summary of Action Items

Scribe.perl diagnostic output