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

On 7/7/2011 2:01 PM, Tab Atkins Jr. wrote:
> 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.)
The x/y offset are there, the font size is inherited, but likely
specified elsewhere; you're correct in that the width and height
are determined by the UA.

I was thinking of path objects, such as circle, and path.

>
>>> 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).
Canvas does not have line breaking; it has to be handled by the author.
It can be a lot of work.

I don't think the text attributes of either Canvas nor SVG are comparable
to the flexibility of CSS line boxes.

When we worked on textarea with Canvas, we use CSS line boxes
as an implementation guide.

Rendering of text is a very controversial issue, I'd prefer to stay away 
from it,
as we've placed the appropriate issue reports and have signaled so to 
the chairs.
>>> 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.
Multi-line text is a lot of work in Canvas; not too useful a demonstration.
Sorry about the error. It should have been:

context.fillText(text.textContent,x,y);
context.rect(x,y,context.measureText(text.textContent).width, fontSize);

This is not the first time I've made that mistake. I use DOM nodes
often, anyway, as part of i18n and supporting online translation
services like Google Translate.


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

Well, I really was thinking about <circle> and <path> when discussing 
things,
they're more appropriate for the use cases we're currently analyzing.


>>> 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).
Could you give me a little more info/a link or time to the example 
you're looking at?
It's likely the author will be working from an organized data set, an 
array or object;
I doubt they would need to go out of their way.



>>> 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.
That has not been my experience, as often, a great deal of the subject 
matter
is about how it's achieved, not when or how soon, but how.

I have much more of a focus on cost and completion dates.

And yes, I also care very much about being apply to apply the method,
as soon as I can, in my work. It is very much a reflection of my work
on  complex canvas applications, that I am interested in a11y solutions
for Canvas apps.

I did undertake HTML forms in part for similar reasons as the pdf.js
crew: "Building an HTML5-based PDF renderer would also answer the 
question of whether
the web platform and in particular canvas and SVG APIs are complete 
enough to efficiently and faithfully render PDFs."

I have the same curiosity regarding the CSS box models implemented in 
SVG and Canvas.

It was through that undertaking that I found minor defects in the Canvas 
spec.

I consider it an empirical pursuit.

There have been some really fun implementations of older software with 
Canvas; including video game emulation of old video games, such as the 
Game Boy, and there have been implementations of other formats, such as 
Flash.

Seeing them implemented in ECMAScript and running on multiple browsers 
to me, seems like a step forward,
and provides a wonderful source of documentation on historic software.


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

Thanks. Yes, that is the e-mail:
Canvas Accessibility for Pointer Events and Spatial Awareness

-Charles

Received on Thursday, 7 July 2011 21:38:48 UTC