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

Steve Faulkner, Tue, 8 Mar 2011 10:06:24 +0000:
> Hi Laura 
> How did you come to the conclusion it is not a viable solution?

Viable solution to which problem? 

* Did you mean a "viable replacement-for-<img@longdesc solution"?
* Or "viable solution to <object@data=image's real-world problems"?

If you meant the former, then the reasoning in Laura's change proposal 
explains very well why it isn't a viable solution. [1] But if you meant 
the latter, then it looks as if it could be a viable solution. Laura's 
change proposal is however about the former and not the altter. Hence I 
choose to believe that Laura did not express herself about wether it is 
a solution to the latter problem.

But, once again, which @role would the canvas@src in Tab's example get? 

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

According to Tab: [2] "The <canvas> element's situation is *directly* 
analogous, as <canvas> represents an image", and I would thus guess 
that many would say it should get role=img, not? However, according to 
ARIA, the children of elements with a role=img SHOULD NOT be presented 
to the user.

I had planned to claim that for <img@longdesc, then the element would 
retain its role=img. In other words: @longdesc doesn't conflict with 
<img's default role - which seems to me like an advantage.

However, this is not quite true. Because BOTH canvas@src AND 
<img@longdesc are outside ARIA's role=img model, which NEITHER has room 
for non-presentational children NOR for the @longdesc link. 

It would be great if some of those who specced ARIA could shed light on 
the @role problem of <img@longdesc and <canvas@src ... Isn't it ARIA 
which needs to change/clarified here?

leif halvard silli

Received on Tuesday, 8 March 2011 14:48:16 UTC