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

Steve Faulkner, Mon, 7 Mar 2011 13:40:15 +0000:
> This is a proposal Tab sent to the WHATWG mailing list 
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/030766.html

> 2. @alt is fine [...] but some images are complex [...]

> 3. To fix this, @longdesc was added, [...] [which] has several
> problems, [...] realize that the value [...] should be a link

Many developers DO get it's a link, but misuse it to link to "long 
images" instead of long descriptions.

>  Second, [...] 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. [...]

If it had the same level of support as @alt, we would have come a long 
way: it should be rendered to a sighted user when the he/she disables 
image display. Then authors would've been able to check how it works 
*for those which (most) need it*.

> 5. The <canvas> element's [...] 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. [...]

The only way to eliminate linkrot in the fallback of a canvas or object 
is to not use anchor or area elements inside the fallback! In fact, 
there are at least 3 important similarities between @longdesc and 
fallback:

1) One can have unhelpful URLs inside @longdesc just as one can have 
   unhelpful fallback inside <canvas>/<object>/<video>. 
2) One can forget to update @longdesc just as one can easily change 
   @src/@data, without updating the fallback. Btw: Upon disabling 
   images, what major browser does then display object's fallback?
3) On can do  <img longdesc=data:text/html,Lorem%20Ipsum src=img>
   (that is: one can use a data URI) and thereby embed the long 
   description DIRECTLY inside the img element, just as one can
   embed fallback directly inside the object/video/canvas element.

> [canvas dependence on scripting make it] inaccessible for visual users 
without 
> javascript, or  for user-agents like feed readers that don't run script. 
[...]

What's the feed "survivability" for this:

> <canvas src="complex-chart.png">
>   <table>
>     -data that the chart represents-
>   </table>
> </canvas>

Versus this:  <img longdesc=URL src=img >  ?

> 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?

I think the idea to make <canvas> become what <img> - or rather: 
<object> - should have been, is a good idea. Because <object> doesn't 
work so well, for many reasons: Even many AT/screenreaders do not 
support fallback of the object element very well - perhaps the AT 
support is on pair with AT's @longdesc support - or is it worse? To use 
ARIA to fix the problem with <object data=image>...</object>  works, 
but only to a degree - only for very simple markup, last I checked. For 
instance, I doubt that it works for tables as children.

But the comparison with <details> seems odd to me: For <details>, users 
first usually get a "summary" in the <summary> element, which they they 
can use when deciding about looking at "the details". There is no 
similar thing in <canvas>. (At least as long as we literally keep for 
example the @aria-label out the picture.)

I am curious to hear what the ARIA experts think about your idea. In 
particular: which @role - if any - should a canvas element that is 
embedding a table in the fallback have? Should it get "table role"? 
(This question is relevant to <object> too, of course.) It can't have 
role="img", because ARIA says that that AT should not make the children 
of elements of role=img accessible.

What I don't agree with you about, is if you see <canvas> as the "homo 
erectus" in a kind of evolutionary history which began with <img>, via 
<object>. Perhaps <canvas> *could* become the preferred element for 
"complicated images in need of complicate markup as fallback". But 
unless you also staff <canvas> with its own link attribute (aka 
@longdesc) and teach authors how to use <canvas> for images which only 
needs 'simple textual equivalents' (aka @alt), then <img> serve its own 
need. 

Leif Halvard Silli

Received on Tuesday, 8 March 2011 02:55:08 UTC