Minutes: HTML Canvas Accessibility Meeting August 21, 2009

Sorry, I saw these were member confidential. I am resending so people can
see the minutes. ... now they are not :-)
http://www.w3.org/2009/08/21-html-a11y-minutes.html

- DRAFT -
Canvas accessibility
21 Aug 2009


See also: IRC log


Attendees
Present
      Cooper, dsinger, Eliot_Graff, Stevef, jcraig, Rich_Schwerdtfeger,
      Frank_Olivier, cyns, mjs, Shepazu, David_Bolter
Regrets
Chair
      Rich_Schwerdtfeger
Scribe
      Rich, Steve, Stevef
Contents
      Topics
      Summary of Action Items









<dsinger> dsinger is Dave Singer, Apple


<dsinger> jcraig is James Craig, Apple


<richardschwerdtfe> chair: Rich


<dsinger:> mjs is Maciej, Apple


<mjs> hello


<richardschwerdtfe> scribe: Rich


<mjs> are people still talking?


<mjs> not sure if I got disconnected...


<kliehm> alas cannot call in to the telcon


<mjs> redialing


<richardschwerdtfe> scribe: Steve


<Stevef> scribe: Stevef


<kliehm> I'm still in hospital on my mobile, and VoIP callthrough doesn't
work, not the conference bridge's fault


richS: theres a wiki http://esw.w3.org/topic/HTML/AddedElementCanvas
... can draw anything on canvas, want author to do that but still support
accessibility
... drawing objects are usually tied to graphic context (not unlike canvas)
... need to define a way how we can associate and API to the discrete
objects, object model defines a heirarchy
... what aria has done is try to leverage object model that was already
there, under the covers a lot of the accessibility heavy lifting done by
browsers, send info to AT
... e.g in mozilla, rich text api is exposed in mozilla, but in cnavas is
bypassing the wholle interaction layer, need to provide access to an object
model, provide an object model we can attach to device contexts, not
dependent on standard conetnt model found in html
... know all worried about performance, not attempting to include CSS etc,
this is par to fo the solution, there are instances e.g bar graph -
solution here is for canvas element to provide html equivalent in HTML.
proposing DOM because developers are familiar with concept


<...richardschwerdtfe> steve are you scribing?


mjs: agrre with basic suggestion on DOM, expand remarks, conerns - whole
point of using canvas is to avoid overhead - not correct reasoning, as its
DOM is higher level)


<richardschwerdtfe> thanks


<jcraig> q


<jcraig> q_


mjs: having high level DOM, just reflecting bits user can interact with


<mjs> I had 3 main points


richS; agrees with mjs,


<mjs> 1) a DOM for acessibility is not unacceptable overhead - the DOM
abstracts at a higher level than the level of drawing operations, you only
need one element per user-visible/interactable feature


<mjs)> 2) focus for "widgets" inside the canvas could also be handled via
DOM, by adding a requirement that anything inside the canvas's DOM subtree
with a tabindex must still participate in the tab cycle and produce focus
events


<mjs)> 3) even text editing, cursor position and selection can be reflect
by nesting a <textarea> or contentEditable area that's an ARIA liveregion,
and updating it with currently visible text


<Zakim> cyns, you wanted to say that perhaps this could be similar to the
table object model in HTML 5? It has methods that deal with table-related
stuff (add row etc) rather than using


cyns: DOM useful to certain extant, maybe more useful to have some more
common API calls, would be useful for people used to working with driect
draws, must work with people who create widget sets to ensure they put them
into the libraries


<Zakim> MichaelC, you wanted to ask does the DOM for accessibility use the
same elements as the W3C DOM or is it a separate object model that user
agents need to support? and to ask if


MichaelC: does the DOM for accessibility use the W3C DOm, and is there any
Accessibility API implication for providing this lightwieght DOm


RichS: want to keep same w3c DOM, but will need some extra interface added,
e.g bespin had a caret, need to be able to expose that to AT


<Zakim> jcraig, you wanted to answer cooper's question


MichaelC: based on W3C DOM, and additional interface needed


<mjs> jcraig is speaking


<davidb> Zakim:, Mozilla is David_Bolter


Jcraig::, in a programming API, you may have certain bits that are
irrelevant to accessibility APIs, mjs was referring to leaving out these
bits, but still use W3C DOm


<richardschwerdtfe> welcome David


jcraig: additional APIs, currently no laternative to DOM mutation events,
not a really good way for javascript app to know about that change


<Zakim> mjs, you wanted to say, DOM+ARIA is already pretty close to the
common denominatory of platform accessibility APIs


jcraig: expressed reservations


mjs: may need additional paralell API, thinks its not necessary, DOM + ARIA
is already pretty close, don't need to do again, use of DOM + ARIA, higher
level ajax libraries could use the same mehcanism, to address james
comment, not usual for browsers to change stuff from under DOM...


richS: could use activedescendent instead of tabindex, assign an ID to an
element


mjs: reason i suggested tabindex, is because of non mouse users


shepazu: was underimpression that DOMand ARIA was suitable for canvas, due
to cnavas being immediate mode, can you explain why your'e OK/


mjs: adding some dom + ARIA does not slow things down compared to SVG
... only need 1 object for 4 or 5 objects, or purely decorative objects
that don't need to be represeneted in the DOM at all


shepazu: SVG is intersted in making a simplified DOM to make paths and
shapes and intersted in having canvas in SVG, may be applicable to canvas


cyns: repsonse to mjs: probably could get by with DOM + ARIA, butis clunky,
while ARIA is useful technology, its a bridging tech for HTML, may end up
in situations where things are a bit odd


<shepazu> http://schepers.cc/w3c/svg/api/cog.svg.


mjs:: may have a point, just using dom + aria may be clunky, but deployment
time is much longer for creating a new API, concerned about designing a
large new API, without using existinbg APIS in browser, how far can we get
with what we have


<shepazu> Common Open Graphics API


cyns: ARIa 2 needs to be in order to fix other stuff, how would ARIA 2
interact with canvas etc/


richS: we will have states and propeorties regardless, by applying them to
the DOM, the author does not have do anything when an event is fired,
browser does a lot of the havy lifting, we don't need an API for
relationships, where we need an API (maybe) is rich text and caret position
... won't need an extensive API, tgher are some thing that are not
incvluded in ARIA that will need to be added at some point, example UI
automation has features that amy need to be incldued in the future


<richardschwerdtfe> `q?


<richardschwerdtfe> ack


<Zakim> MichaelC, you wanted to say ARIA 1.1 or ARIA 2.0 could be on the
table to address canvas-specific holes


MichaelC: cyns covered most of what i wnated to say, if we encounter holes,
an ARIA 1.1 may happen


cyns: still worry about things in regards to adding things later


mjs: clarification, in regards to replacing whole canvas, chaals had a bar
chart, created a html table wanted to be able to present user with it


richS: whats the current mechanism? for swapping canvas with its fallback?
... the things that has been happening in the learning space is to define
metadata, where the resource (canavs) can be swapped out automatically. e.g
for a google map written in canvas alternative may be text based riving
directions. looking at this in mashups, would we want to introduce this
into HTMl 5?


mjs: sounds intriging, not just tied to vcanvas accessibility, but need to
see more details


<richardschwerdtfe,> http://www.imsglobal.org/accessibility


richS: what we do agree on - use a W3C DOM to house the object model for
the accessibility states and properties


cyns: has some reservations but is willing to go forward with it


richS: dodn't say we don't need an API


<kliehm> +1 on the DOM


<richardschwerdtfe> +1 DOM


shepazu: DOM of what?, talking about methods and proeprties, what would the
represented "markup" be?


michaelC: DOM would only represent that its a button, no rendered button,
but not visually rendered


<shepazu> s/talking about methods and proeprties, what would the
represented "markup" be?


cyns: a html button on windows is a win32 button and has lots of
properties, these are the kinds of issues i am concerned about


mjs: thinks controls are not directly mapped to OS controls


cyns: one of the best things about html is that you get a real button


mjs: cnavas not a context for having a real button


sheapzu: use of neutral element in canvas DOM, richS agrees,


shepazu: may morph into something like XUL


<mjs> fwiw I have a hard stop at noon pacific (in 3 minutes)


<richardschwerdtfe> will get you david


davidb;


davidB: not clear on who is providing the markup that is being serialized
into a DOM


<richardschwerdtfe> scribe: Rich


<richardschwerdtfe> SteveF: need to drop off


<richardschwerdtfe> Rich: can we meet again next week


<davidb:> davidb: I'm happy with the notion of the web dev programmatically
creating the dom (not sure who answered me).


<mjs> I won't be free at all next Friday but in general I'm willing and
able to meet again


<richardschwerdtfe> jcraig: browsers need to allow focus management with
canvas elements where there is a DOM


<richardschwerdtfe> Rich: Do we need some sort of mapping between the DOM
element and the canvas?


<richardschwerdtfe> mjs: I don't think it is sufficient to be able to refer
reference the canvas to the DOM elements due to the DOM elements


<richardschwerdtfe> jcraig: I think this could be done via pseudo CSS
positioning to position the DOM related to the elements on the screeen


<richardschwerdtfe> mjs: If wanted positional navigation a user agent could
do this


<richardschwerdtfe> mjs: I am very interested in this as Apple created the
canvas element


<davidb> discussion: prototyping mockups


<richardschwerdtfe> jcraig: we could prototype this today


<richardschwerdtfe> jcraig: we could fake the shadow tree. We don't have to
make them *inside* the canvas.


<richardschwerdtfe> david: I understand


<davidb> i nominate cyns


<richardschwerdtfe> doug: Prototyping this would take a half an hour


<richardschwerdtfe> doug: make a fake user interface


<richardschwerdtfe> jcraig: you can make it and I could add the aria
semantics


<richardschwerdtfe> doug: I can try it


<cyns> I need to go. Talk to you next week.


<richardschwerdtfe>
http://codetalks.org/source/widgets/listbox/listbox.html


<richardschwerdtfe> meeting: ARIA Canvas discussion


<richardschwerdtfe> chair: Rich


Summary of Action Items

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist