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

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 09:43:51 UTC