Re: hit testing and retained graphics

Hi, Charles-

Charles Pritchard wrote (on 7/6/11 3:07 PM):
> Adobe has released several canvas export tools; accessibility is part
> of authoring tool guidelines.

Adobe has also released several SVG export tools, and I would like to 
see them release more.


> Unfortunately many browser vendors have been underserved by their
> teams and/motivations: they are pushing back against supporting a11y
> for canvas content.

Please stop using rhetoric like this.  It is incorrect and perhaps even 
disingenuous.  It makes people defensive and is a barrier to reasoned 
discussion.

Browser vendors have not pushed back on "supporting a11y for canvas 
content", they have pushed back against adding a retained-mode component 
to the Canvas 2D API, for obvious reasons: the Canvas 2D API is intended 
for *immediate-mode* graphics, and we already have a 2D graphics 
standard for the Open Web Platform: SVG.


> Vendors of authoring tools are not even able to
> expose the accessibility information that might otherwise be shared.
> Many browser vendors are indeed discouraging it with a vague promise
> of future specs.

Again, this seems to be rhetoric.  I haven't heard any browser vendor 
offering any future work in this area.  I have proposed what seems to me 
like a reasonable solution, which is an API that allows the two 2D 
graphics APIs (Canvas and SVG) available in all major browsers to be 
used together.  You have claimed this is "overkill", but have not stated 
why.

I find it frustrating that we have a point on which the browsers seem to 
agree (that SVG is the retained-mode graphics option), but rather than 
building on that foundation, you persist in pursuing a redundant 
approach that the browser vendors have already rejected.  Is this NIH 
syndrome on your part, or do you have some specific technical reason for 
rejecting my proposal?  If so, please state your objection clearly, 
without hand-waving.


I have serious reservations *from an accessibility point of view* about 
extending the Canvas 2D API toward retained-mode or subtree logical 
structures further than it has already been pushed.  To wit:

* Issues that have been solved in SVG around the scaled viewport, around 
rich object structure, around smooth scaling (for crisp displays at all 
sizes), around shapes which move and change size or shape, and so on, 
are still problems that accessibility in the Canvas 2D API has yet to 
pose, much less to solve.

* Your proposed solution of adding an element to the canvas subtree 
which carries shape, size, and location information seems to be simple, 
but only because you haven't carried it to its logical extreme, which 
will ultimately be to reinvent SVG (perhaps slightly differently, so 
that it's not even compatible).  Where does it stop?  When is 
accessibility potential of Canvas complete, and not only available, but 
either encouraged or mandatory, with your approach?

* Your approach either either requires the user to maintain the position 
it themselves, in which case Cameron's aria-region suggestion [1] seems 
better and is already reasonably defined as a starting point, or would 
be done automatically, in which case SVG would be better and is already 
defined (though admittedly, how it works precisely with SVG would also 
need to be defined, implemented, and tested).


[1] 
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0067.html

Regards-
-Doug Schepers
W3C Staff Contact, SVG, WebApps, Web Events, and Audio WGs

Received on Thursday, 7 July 2011 16:51:39 UTC