Re: hit testing and retained graphics

Rich Schwerdtfeger
CTO Accessibility Software Group

public-canvas-api-request@w3.org wrote on 07/07/2011 11:51:20 AM:

> From: Doug Schepers <schepers@w3.org>
> To: Charles Pritchard <chuck@jumis.com>
> Cc: Karl Dubost <karld@opera.com>, "Tab Atkins Jr."
> <jackalmage@gmail.com>, Charles McCathieNevile <chaals@opera.com>,
> Henri Sivonen <hsivonen@iki.fi>, "public-canvas-api@w3.org" <public-
> canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>,
> "public-html-a11y@w3.org" <public-html-a11y@w3.org>
> Date: 07/07/2011 11:51 AM
> Subject: Re: hit testing and retained graphics
> Sent by: public-canvas-api-request@w3.org
>
> 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.
>

Hit testing could be implemented in Canvas without full retained mode
graphics.

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

At least for accessibility, browser vendors have inconsistent ARIA mappings
to platform accessibility API and in the case of IE it is non-existent. I
have not looked at Safari or Chrome. Also, I have not seen a rich semantic
object tree made available for SVG that would provide containment structure
(e.g. menuitems being children of menus as could be determined from the
DOM). One of the benefits of being able to embed SVG elements in canvas is
that you could use the same fallback content but again I would want to bind
SVG elements to it programmatically.

What I am saying is we have a lot to consider with SVG besides the retained
mode graphics which I like. I am sure you have also spoken with John
Gardner and he has shared his frustration about the browser
inconsistencies.

I am also surprised that the browser vendors cannot give you an answer to
your proposal.


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