Re: You Got Your SVG in my Canvas! Mmm, Delicious!

On 7/7/2011 10:30 AM, Tab Atkins Jr. wrote:
> On Wed, Jul 6, 2011 at 6:31 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>> "easiest solution" for whom?
>>
>> Other than politics, I don't see how this is the easiest.
> Well, solving use-case #1 (allowing an AT to read out text in the
> drawing that the user indicates) is solved for free with SVG.  That's
It's not solved for free; it's solved by the author exposing path data 
to the UA.
> a lot easier than how I imagine it would be in canvas 2d, where you'd
> draw the text, then figure out the bounds (which requires some API
> additions, I think, to know how long each line ended up being and how
> many lines there are), then duplicate the drawn text in the
We have measureText to figure out the "bounds". It's the same code path 
used by the browser.
> accessibility subtree, then set up a bounding path that points back to
> the text in the tree.  Most of this work has to be repeated if the
> text moves around in the image.
[canvas][div id="myText"]This is text[/div][/canvas]
var text = document.getElementById('myText');
context.fillText(text,x,y);
context.rect(x,y,context.measureText(text).width, fontSize);
context.setElementPath(text);
// DONE!.

> Use case #2 (getting a caption or description associated with a region
> of the image) isn't free, but it's very simple.  In the video for the
> AT that I extracted the use-case from, the user clicked on some points
> in a graph, and iirc got a readout of the trendline that the points
> represented.  In SVG that would be something like this:
>
> <svg>
>   [boilerplate]
>   <g>
>    <desc>[trendline caption]</desc>
>    <circle ...>
>    <circle ...>
>    [more points]
>   </g>
> </svg>
>
> The only difference between the "accessible" version and an
> "inaccessible" is the<desc>  element itself, and possible the use of a
> wrapper<g>  (though there's a good chance that an author would already
> have used a<g>  there for styling purposes).
>
> The canvas2d solution would be slightly more difficult, because you
> have to figure out the bounding path yourself.  It's otherwise roughly
> the same.
Implementations of Canvas in the UAs have a private get bounding path 
method;
this is already handled by the UA.

The author simply runs  their path commands, as they already do.

> Use-case #3 (indicating the bounds of an active region, so magnifiers
> can zoom to it) is similarly easier, because you just have to focus an
> element in the SVG tree.  In the canvas solution you again have to
> first create a bounding path, attach it to an element, and then focus
> the element or something similar.
>
>
>> As others have pointed out, it is a diversion anyway. We're trying to finish the Issues with Canvas a11y that were brought up two years ago. "Don't use Canvas" is not a solution.
> No we're not, or at least, I'm not, and you shouldn't be.  We should
> be trying to fix accessibility problems that we find users have,
> utilizing the best tools we can provide to authors.  If that involves
> tweaking Canvas, that's fine, but tweaking Canvas should not be the a
> priori goal of this exercise.
This is public canvas api; I have several canvas based applications,
and the thread is about canvas accessibility.

I work on accessibility, I work with Canvas; yes, I should be working
with Canvas accessibility.

>
>> I have surveyed developers, I've worked on AT and on implementations.  Passing the path and bounding information via method call is quite easy for vendors, authors and spec editors. The difficulty here is entirely in the mind of those confused few who mistake this simple solution for something sinister.
> I don't feel there's anything sinister going on.  I have two
> reservations, which I've stated previously.  The first is that I can't
> tell what problems you're attempting to solve, and so it's impossible
I posted use cases, per your request. Were they insufficient?
> to evaluate your proposed solutions.  We're gradually addressing this,
> though, by extracting and listing use-cases (again, I've began listing
> these at<http://wiki.whatwg.org/wiki/Active_Image_Accessibility_Use-cases>).
>   The second is that, while you may have expertise in various relevant
> regions, I'm not sure you have expertise at designing good API that
> utilizes incentives to ensure it's used often and correctly.  This is
> also something that can be addressed by gathering use-cases, as that
> allows many people to contribute and help find solutions, including
> those that I'm confident are good at this kind of design.

Richard suggested that UAs support a setElementPath which marshals 
pointer-events,
precisely for these reasons. You're correct, I do not have such 
-expertise-, I was satisfied
with simply exposing the path data / bounding box to the AT, and 
possibly having a stringify
extension to make development a little easier.

Still, I've taken those motivations to heart; and based on your 
comments, that seems like
the right thing to do.

Received on Thursday, 7 July 2011 17:47:51 UTC