- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 8 Mar 2011 11:13:53 -0800
- 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