- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Tue, 8 Mar 2011 10:06:24 +0000
- To: Laura Carlson <laura.lee.carlson@gmail.com>
- Cc: HTML WG LIST <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, "jackalmage@gmail.com" <jackalmage@gmail.com>
Hi Laura How did you come to the conclusion it is not a viable solution? Regards Steve Sent from my iPhone On 8 Mar 2011, at 09:43, 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]. > > Best Regards, > Laura > > [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 > > On 3/7/11, Steve Faulkner <faulkner.steve@gmail.com> wrote: >> Resent with full context (apologies for earlier mail sent accidentally due >> to a combination of small screen and fat fingers) >> >> This is a proposal Tab sent to the WHATWG mailing list >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/030766.html >> >> I think it has a lot going for it. >> What I would add is a native ( non JavaScript) method of displaying the >> alternative content as a range of people would benefit from being able to >> switch between the canvas and the structured alternative. >> >> Proposal for >> <canvas src> to allow images >> with structured fallback by >> Tab Atkins Jr. >> >> "Allow me to quickly summarize >> the state of affairs and the >> problem I >> wish to solve: 1. <img> was designed in a >> broken manner, as it is a purely >> visual >> element with no way for non- >> sighted users, such as blind >> people or search engines, to view its >> contents. To fix this issue, @ >> alt was >> added to <img>, to provide a >> textual alternative to the image. 2. @alt is fine for images with >> simple textual equivalents, but >> some >> images are complex and can't >> be easily described in a single >> unstructured paragraph. For example, a complex graph may >> be best >> represented in textual form by >> presenting the data used to >> generate it >> in the form of a <table>. 3. To fix this, @longdesc was >> added, which is a link to >> another page >> with a longer, and possibly >> structured, alternative >> representation of the image. This has several >> problems, however. First, data >> shows >> that many users of @longdesc >> don't realize that the value of >> the attribute should be a link to a >> page representing the longer >> description, and instead either >> point it to the embedding page >> or the >> image itself, or just fill it with nonsense. Second, the fact >> that >> the long description is a >> separate page means that it's >> possible that >> the linkage can be broken if the server is reorganized or the url >> structure of the site is altered, >> or if the code containing the >> <img> >> is copypasted between pages. >> Since the long description is not presented at all in all major >> visual user-agents, a breakage >> can go a >> long time before being >> detected. 4. Some other elements, such >> as <object> and <video>, have >> conceptually similar issues, >> where they want to present >> alternative >> content in case their main content is unusable or >> unrecognized. These >> elements encode the fallback >> content as direct descendants, >> hiding >> them when they're not necessary. 5. The <canvas> element's >> situation is *directly* >> analogous, as >> <canvas> represents an image, >> and contains textual/structured >> alternative content as descendants. The problems >> with @longdesc >> described in #3 are not present >> in <canvas> - the descendants >> are >> clearly alternative content, and travel inline with the element, >> making them immune to linkrot. It thus seems that <canvas> >> represents a strictly better >> alternative >> to <img> when structured >> accessibility fallback content is >> required, except for one problem - >> <canvas> can only be scripted. >> To use it as >> an image, one must also run >> some javascript with creates an >> out-of-document <img> element, points it at the >> appropriate image, and >> then draws it into the canvas. >> This is inaccessible for visual >> users >> without javascript, or for user- agents like feed readers that >> don't >> run script. I suggest that we can retain all >> the benefits of <canvas> over >> <img >> longdesc> while avoiding the >> above problem by adding an >> optional @src attribute to <canvas>. If >> present, the image linked by >> the attribute >> is loaded and drawn into the >> <canvas> automatically, >> without any script intervention required. >> <canvas> would then fire the >> same >> events that <img> currently >> does and generally expose the >> same API, in addition to the current canvas >> API. It would be used like: <canvas src="complex- >> chart.png"> >> <table> >> -data that the chart >> represents- >> </table> </canvas> I've discussed this privately >> already, and one of the >> objections to >> this proposal was that @ >> longdesc allows the user-agent >> to delay loading the alternative until the >> user actively requests it, as it's >> not always ideal to drop a large >> structured alternative into the >> middle of content (similar to >> how sighted users can just skip over a >> complex chart, returning to it >> later when they have more time >> or >> attention). I don't believe this >> is a valid objection - there is nothing requiring a screen- >> reader to automatically present >> the >> alternative content to the user. >> UAs must already have ways to >> delay showing in-band information >> until requested, so as to >> correctly >> represent the <details> >> element, for example. The >> same mechanism can be used for <canvas>; while I'm >> not in any place to recommend >> UI for >> screen-readers, it may even >> make sense to present >> <canvas> and <details> in a unified fashion. Thoughts on the problem or >> the proposed solution >> presented here?" >> >> >> Sent from my iPhone >> >> > > > -- > Laura L. Carlson
Received on Tuesday, 8 March 2011 10:11:21 UTC