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

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

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Tue, 8 Mar 2011 15:32:28 -0600
Message-ID: <AANLkTimr0oTWLStO+128QacVEr==mDOtS=YPpLsKBjyw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@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>
Hi Tab,

Thank you for your comments. I am sorry that you don't understand the
change proposal, Tab. I'll work on trying to improve its clarity. But
in the mean time a few comments.

The point is that none of the "suggestions" presented to date are
functional replacements for longdesc. None of them solve the all of
the use cases.

Even if the canvas contortion could be an alternative to longdesc in a
few situations why add such needless complexity in an attempt to
reinvent the wheel?

Related solutions do not negate the need for longdesc.

longdesc should be included in HTML5

> * The point of <canvas src> is that it should be able to function as a drop-in
> replacement for <img src>.

I don't consider img broken. But if you consider img broken, it may
more productive to concentrate on fixing img rather than contorting

Best Regards,

On 3/8/11, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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 [2]. 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
 [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/030766.html
[2] http://lists.w3.org/Archives/Public/public-html/2011Mar/0156.html
[3] http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#.3Ccanvas_src.3E
[4] http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Suggested_Alternatives_Are_Not_Viable_Solutions
[5] http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc

Laura L. Carlson
Received on Tuesday, 8 March 2011 21:33:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:53 UTC