W3C home > Mailing lists > Public > public-html@w3.org > July 2011

Re: hit testing and retained graphics

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 7 Jul 2011 12:01:49 +1200
To: Charles Pritchard <chuck@jumis.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Charles McCathieNevile <chaals@opera.com>, Henri Sivonen <hsivonen@iki.fi>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-canvas-api-request@w3.org, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
Message-ID: <20110707000148.GC21787@wok.mcc.id.au>
Charles Pritchard:
> We've made progress on keyboard events via drawFocusRing and the
> shadow dom with the existing canvas 2d context. I don't see why
> pointer events warrant forking to a completely new context.

I don’t think need to invent a whole retained mode version of <canvas>
or a new context.

We’re not solving all accessibility problems with <canvas> here.  For
the general problem of making arbitrary graphical content accessible I
agree we should encourage the use of SVG and improve SVG’s
accessibility.

Here is how I see the problem at hand:

* we are drawing HTML form/UI control like content to the <canvas>
* we have a subtree of the <canvas> that contains the form elements
  which have funky presentation on the <canvas>
* the subtree elements are used to manage focus
* magnifiers need to know the bounds of the currently focussed element
  so that the screen can be zoomed to it
* the actual form elements in the subtree aren’t being rendered, so we
  can’t use their bounds to give to the accessibility APIs
* we need to inform the magnifier of the bounds of the currently
  focussed element

Since we are already using the subtree elements to represent the
accessible version of the <canvas> content, it makes sense to associate
the subtree elements with the region of the <canvas> that represents
them.

In this situation authors are already committed to creating and
maintaining the <canvas> subtree to make their application accessible.
It seems to me that the simplest solution, as I mentioned in another
branch of the thread, is to annotate the subtree element with the region
on the <canvas> that is being used to represent it, using a DOM
attribute aria-region="" or something.

The reason why I think it is feasible to require setting an attribute
explicitly and not to have the association done automatically because of
calls made on the canvas context is that the author already must
maintain the subtree manually.

A question: do mangifiers just need a rectangle or do they need a
general path?  Can someone point me to the APIs that would be used by
the implementation to communicate the currently focussed region?

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 7 July 2011 00:02:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:26 UTC