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

On Thu, Jul 7, 2011 at 10:47 AM, Charles Pritchard <chuck@jumis.com> wrote:
> 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.

I don't understand.  Take the following:

<text x='10' y='50'>Molar concentration (M)</text>

What path data is present here, other than what the author provides to
the UA to tell it how to draw?  (That's what I mean be "for free" -
the author doesn't do anything beyond what they were already wanting
to do anyway.)


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

measureText provides a bounding box.  That's sufficient in many cases,
though not always (if the linebreaking produces a sufficiently jagged
edge, or if the last line is very short).

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

Ah, I'd forgotten about measureText.  Your code is slightly incorrect
(it passes an element to fillText and measureText, and forces
single-line, which won't be correct in general), but they're trivial
fixes.

That's still not ideal in all cases (due to the jagged-edge issue I
raised above), but it is simpler than I assumed.  Still not free,
though.  ^_^


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

Could you illustrate this like you did with the previous?  It actually
seems like a much more difficult problem, since you want to associate
each of the individual circles with the description, not a huge
bounding rectangle.  This doesn't seem to work with setElementPath
unless the author goes out of their way to draw all the circles with a
single path (involving a lot of moveTo).

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

That's a very narrow view, and I believe shows Conway's Law at work
once again.  We care about accessibility on the web, however it's
achieved.


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

This email, correct?
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0034.html

I hadn't yet assimilated that into my list.  I've now partially done
so - I have questions about some of them, though, which I'll bring up
in a separate thread.

~TJ

Received on Thursday, 7 July 2011 21:02:51 UTC