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

Hi Tab,
The neat thing about your idea is that it can be used  without adding the
src attribute using a few lines of Javascript.
and will be supported once browsers implement the navigable DOM as specced
(like IE have done).

So it does not need to be in competition with longdesc as the one true
method of providing a structured text alternative in HTML5
I think that I for one will be promoting its use in providing a structured
text alternative when browser support is up to scratch just as I will/would
be promoting the use of longdesc if its browser support was up to scratch.


regards
Stevef





On 8 March 2011 19:13, 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 [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
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html