Re: Adaptive Image Element Proposal

Steve Faulkner, Fri, 31 Aug 2012 20:14:06 +0100:

Just a words on what you said complication, Steve: I think it is the 
fact that <picture></picture> currently is modeled after <img />, with 
an alt attribute and everything, that complicates. Ultimately, built 
into the alt attribute idea, lies the img element model or the role=img 
model: A void element where all the alternative text is provided via 
attributes.

> As previously discussed and bugged I do not support the addition of an alt

> The way I envisage <picture> to work is similar to how <canvas> is supposed
> to work

> So until UAs support picture, text alternatives can be supplied via the
> fallback image. It could still be supplied this way for browsers that
> support picture btw.
> 
> <picture>
> <img alt="text alternative">
> </picture>

+1

Perhaps the best thing with the canvas model that the child <img> 
element becomes an integrated part of the <picture>. Which in turn 
removes the need - or wish - to duplicate the alternative text in each 
(fallback) layer. (And thus also removes the need/wisth to get rid of 
duplication via aria-labelledby ...)

Also very good is that the canvas model prohibits that <picture> can be 
given the ARIA 1.0’s img role as its default role. HTML5 permits adding 
role=img to the canvas element. But note that doing so immediately 
causes (at least per the ARIA spec) the content, including the shadow 
DOM, to become hidden from AT - meaning that authors must provide the 
alternative text via attributes.

The object element does not follow the canvas model - with the object 
element, then it is an either-or: Either you get the object element, 
you get its fallback. As a result, to make <object> accessible, one  
must - at least currently - use aria attributes.  (And one probably has 
to apply role=img to it as well.) Hence I am sceptic about the object 
model here. The hybrid canvas model seems much more fruitful.

But as we discuss adding longdesc to <img>, then I don't quite 
understand why we should not allow interactive content in <picture>. 
Perhaps there should be restriction, though - OK. But not forbiddance, 
me think. And by the way: Would it be authors or AT/UAs that decided 
the interactivity? E.g. would an <a href> sease to become interactive 
when inside <picture> or would this be an authoring rule thing?
-- 
Leif Halvard Silli

Received on Saturday, 1 September 2012 02:41:10 UTC