Re: correct and incorrect uses of canvas

On 7/14/2011 1:40 PM, Jonas Sicking wrote:
> For what it's worth, I do think that while a lot of these are
> "invalid" uses of canvas, I think we need to have a better
> accessibility story for them. In particular, one situation which is
> common, and is likely to remain common, is JS libraries, such as
> processing.js which output to canvas. We can and should improve the
> SVG DOM to attract more people, but I suspect there will always be a
> group of people that choose to use canvas anyway due to better
> performance or other reasons.
I've provided emscripten as another example; I think it goes side by 
side with
the processing.js example you've given.

I've also agree with the performance-or-other-reasons argument. David Singer
made some similar statements:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0179.html

> Ideally setting the area covered by one of these regions should be
> easy to set while performing one or more drawing operations.
>
> Adding something like:
>
> interface CanvasRenderingContext2D {
> ...
>    void setDrawingFor(in Element target);
>    void clearRegionFor(in Element target);
>    void clearAllRegions();
> ...
> };
>
> might go a long way API wise. The clearRegionFor would remove any
Something similar was proposed by Richard Schwerdtfeger in March 2011:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0090.html
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0090/Canvas2DClickableRegion.html#focus-management
Search for: setClickableRegion in the api change proposal

Richard's proposal has setLastDrawn and lacks clearing methods.
setLastDrawn is a "light" version of z-index.

We have since folded setLastDrawn into the clickable region method as an 
optional z-index attribute.

Richard's take, I believe, was that path clearing methods are not 
necessary as the elements may simply be removed from the DOM
or otherwise cleared by setting the drawing path to an empty path. So, 
there are two methods to clear the region data from the accessibility tree.


> Once a region has been associated with an element, it would act
> similarly to how a<label>  acts. So clicking that region would
> dispatch a "click" event to the element and hovering it would dispatch
> "mouseover" etc.
>
> There are of course lots of unanswered questions, such as if focus
> outlines should automatically be drawn by the UA if an element with an
> associated region is focused. But the above might be a start.
We have drawFocusRing for that, the author should set an onfocus event
on the DOM element and run drawFocusRing as appropriate.

There are times when the author may also use aria labeling,
such as aria-activedescendant.

The author may also choose to manage setCaretSelectionRect

You pointed out there could be some conflicts between those two methods:
http://lists.w3.org/Archives/Public/public-html/2011Apr/0748.html

Generally speaking, such conflicts are handled by the UA and AT;
ATs for instance, have options to prioritize what they follow with 
mouse, caret and focus.



-Charles

Received on Friday, 15 July 2011 02:05:14 UTC