Re: Basic code examples for pointer regions

Hi Charles,

Thanks for the example!

On Wed, Nov 2, 2011 at 5:52 PM, Charles Pritchard <chuck@jumis.com> wrote:
> Jonas, sorry this is a bit lengthy. I've used the Canvas checkbox example as
> well as a fun Canvas demonstration to explain why setPathForElement is
> easier for authors to use and not make mistakes with. It's at the bottom.
>
> ...
>
> TL;DR: setPathForElement requires less work on implementers, authors and
> specification authoring than the beginElement proposal. beginElement would
> be very useful for recording Canvas calls into a retained format such as
> SVG.
>
> Scroll to the bottom for references to existing code.
>
> ...
>
> Following up on various threads about hit testing.
>
> There are two active proposals to manage pointer events with Canvas.
>
> beginElement/setDrawingFor:
>
> setDrawingFor(element) -> setDrawingFor(null)
> or in another form:
> beginElement(element) -> endElement()
>
> The concept is to record path data and bounding rectangles for drawing
> commands issued between the start and stop methods. putImageData and
> drawImage calls would be treated as rectangles, with drawImage subject to
> the current transformation matrix (as is the case).
>
> setPathForElement, was: setClickableRegion
>
> setClickableRegion(element)
>
> The concept is to use the current path in context, and like beginElement,
> associate the path and bounding rectangle to the target element. This method
> does not work with putImageData nor drawImage.
>
> ....
>
> Are they easy for authors to use? Will they support pointer events for AT as
> prescribed by WCAG?
>
> There is a minimal bar for these two criteria:
>
> For ease of use the result of using these methods must be easily
> identifiable as well as enhance the productivity of authors using them.
>
> For WCAG compliance, the methods must, at minimum, record bounding box
> information to expose basic accessibility APIs.
>
> Following from these criteria, in which I believe there is acceptance:
>
> beginElement implementations should have an internal path objects stack --
> though it is possible to implement beginElement for hit testing using only
> bitmaps the resulting data would be practically opaque to assistive
> technologies. Canvas does not require any particular level of precision on
> those path objects. It is very much implementation dependent.
>
> setPathForElement simply uses the path object already present, a series of
> subpaths. Both methods could benefit from using a bitmap to do hit testing
> on performance constrained systems. The subpaths can be used in both systems
> to reproduce and expose vital information to platform accessibilty APIs, as
> well as hit testing and regenerating a hit testing bitmap.
>
> Both methods would increase the productivity of authors as they debug and
> develop their application, they would expose vital information to ATs and
> the results are easily identified.
>
> ....
>
> setPathForElement is all that's needed by authors to fulfil WCAG. Compared
> to beginElement it's shorter with far less restrictions and considerations.
>
> Blob Sallad is an excellent tech demo for interactivity; I use it all the
> time, it has a free license.
> http://www.blobsallad.se/blobsallad.js
> http://www.blobsallad.se/iframedsallad.html
>
> To enable accessible hit testing, I'd go to line 880 in the this.draw
> method:
>    this.drawBody(ctx, scaleFactor);
> And change it to:
>    ctx.beginElement(element);
>    this.drawBody(ctx, scaleFactor);
>    ctx.endElement();
> Or, simpler:
>    this.drawBody(ctx, scaleFactor);
>    this.setPathForElement(element);

This only works because drawBody is able to do the whole drawing as a
single path. What would you do if the bob character required 5
separate paths to be drawn? Or if his eyes were drawn using drawImage
and resided outside his main body (like the cookie monster who's eyes
are on top of his head).

/ Jonas

Received on Friday, 11 November 2011 23:49:00 UTC