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

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

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.

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.


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

~TJ

Received on Thursday, 7 July 2011 17:31:54 UTC