W3C home > Mailing lists > Public > public-html@w3.org > March 2011

Re: Proposal for <canvas src> to allow images with structured fallback by Tab Atkins Jr.

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 8 Mar 2011 11:13:53 -0800
Message-ID: <AANLkTimnwZFeSkcJj1O0jA46coBkv=cCNi1VFYZQK-t6@mail.gmail.com>
To: Laura Carlson <laura.lee.carlson@gmail.com>
Cc: Steve Faulkner <faulkner.steve@gmail.com>, HTML WG LIST <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Tue, Mar 8, 2011 at 1:43 AM, Laura Carlson
<laura.lee.carlson@gmail.com> wrote:
> Hi Steve,
>
> Thank you for bringing Tab's proposal [1] to our attention [1]. I'm
> please that longdesc is being thought about again.
>
> However <canvas src> is not a viable solution. I added <canvas src>
> [3] to the "Suggested Alternatives Are Not Viable Solutions" section
> [4] of the change proposal  to reinstate longdesc in HTML5 [5].

While I'm disappointed that you don't think it's a viable solution, I
understand the reasoning - it attempts to sidestep the "reinstate
@longdesc" issue by defining a better solution for the future.

Unfortunately, most of the points in the section of your Change
Proposal <http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#.3Ccanvas_src.3E>
are incorrect, misleading, or seemingly nonsensical.

* "<canvas src> is not a functional replacement" - It doesn't have
100% of @longdesc's functionality, but it has benefits beyond
@longdesc as well, which I pointed out.  For example, while a document
pointed to by @longdesc can be shared by multiple images (how common
is this?), <canvas src> is resistant to copypaste errors.  Focusing
entirely on "we need a 100% feature replacement for @longdesc" is not
a useful direction, unless you really believe that every feature of
@longdesc is absolutely vital.

* "<canvas src> would be limited to text in the same document" - I
don't understand what this is supposed to mean.  Is it a restatement
of the following point that a single @longdesc document can be linked
to from multiple images?

* "<canvas src> would not permit pointing to external sources... such
as MathML or SVG" - This doesn't make any sense.  <canvas> takes any
valid HTML as descendants, including MathML and SVG.

* "To display an image, an author would have to create a canvas
context. This would make it more prone to authoring error." - This
doesn't make any sense.  Maybe the writer didn't understand the role
that @src would play, and assumed that you'd have to use JS and use
drawImage on a Canvas 2d Context to get the image to display?

* "People don't copy and paste the img elements." - This doesn't make
sense (note - this isn't in full context - the full context is this
line, combined with the paraphrased next point).  The "copypaste
safety" argument that I made was about authors copypasting code.  I
assume that the writer of this point didn't understand what I was
trying to say, and assumed I was making some point about copypasting
the image itself.

* (paraphrased) "[Using canvas breaks right-click 'Save Image'.]" -
This doesn't make sense.  Firefox, for example, certainly exposes
"Save Image" on <canvas> elements.  Chrome doesn't, but this is a UA
issue, and should be fixed in due time.

* "The long description would be forced upon the screen reader user."
- This is incorrect, and I explicitly addressed this in my proposal.
This is an AT issue; ATs can easily decide to expose the <canvas>
descendants only when the user requests it.

* "<canvas src>... does not have an existing base..." - I can't parse
this sentence.  I have a glimmer of what the author was intending to
write, but I'd prefer not to have to imagine the argument when I could
instead just request it be clarified to make sense.

* "Not all images that require a long description will be in <canvas>"
- This doesn't make sense.  Perhaps the writer didn't read my
proposal?  The point of <canvas src> is that it should be able to
function as a drop-in replacement for <img src>.

* "Accessible does not equate to fallback." - This doesn't make sense.
 <canvas>'s fallback is defined to be accessibility fallback.


Once you remove all the nonsensical or incorrect points in the
section, the points left are that (1) <canvas src> isn't a 100%
drop-in replacement for @longdesc, and (2) <canvas src> isn't yet
implemented, so it will take time before its a usable solution.

The second point can be mitigated with a simple polyfill that grabs
the @src off the <canvas>, creates an <img> with the same @src, and
then draws the <img> into the <canvas>.

~TJ
Received on Tuesday, 8 March 2011 19:14:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:23 UTC