Re: hit testing and retained graphics

Rich Schwerdtfeger
CTO Accessibility Software Group

public-html-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:52 AM
> Subject: Re: hit testing and retained graphics
> Sent by: public-html-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.
>

Doug, forgive  me but you make it sounds like you are concerned that if we
add retained mode graphics to canvas that industry will not use SVG. 1. I
don't believe that is true and 2. we are roughly 1 feature away from fixing
canvas accessibility.
>
> > 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.
>
Doug, I personally am just concerned about the technical details of putting
these two guys together. The fact that SVG could be back by an HTML shadow
DOM will help a great deal. ... As we can leverage what works today. I am
concerned that the browser manufacturers have not gotten behind this and I
am still waiting to hear if this is the way the want to go. We also have to
have to deal with shadow

> 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.
>
Doug, I think the problem is that the browser manufacturers have also not
supported the integration of SVG into canvas.
>
> 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.
>
The smoothing of shapes has nothing to do with retained mode. What we are
trying to do is make canvas accessible. SVG is another technology and that
is a separate accessibility effort. If SVG is so wonderful why are you not
pushing for an SVG element in HTML 5? Why have you not pushed to ditch
canvas from HTML in favor of SVG?

Also, the entire Windows platform has been very successful, in terms of
accessibility, for years without these features. This is not a valid
argument.

Finally, on this point. When a developer picks a technology they do it
based on a number of factors. Canvas already has been used my many open web
applications. It needs to be able to support accessibility if this is the
developers choice.

> * 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?
>
I did not see that proposal. We were suggesting adding creating path
objects in the canvas 2D API and bind them to existing subtree elements.
For example:

<canvas>
   <div id="foo" role="checkbox">
...
</canvas>

pseudo code in canvas 2D API:

path = new Path();
...
checkbox=document.getElementFromId("foo");
context.addClickablePath(path, id, z-order, checkbox); /*At this point
assign the bounds to the fallback content object's accessible object and
sort the paths in terms of z-order

Now,

For the pointing device handler in canvas:

receive an event
cycle through path in terms starting with the highes z order {
   If the point is in the path dispatch the event to the corresponding
element and exit
}

There are a few other details that are needed but this is a far cry from
the full retained mode graphics in SVG.


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