Re: Adaptive Image Element Proposal

On Sep 4, 2012, at 4:41 PM, Leif Halvard Silli wrote:

> Adrian Roselli, Tue, 4 Sep 2012 20:14:46 +0000:
>> I'd rather see <picture>'s fallback rely on the existing momentum 
>> <img> has with its @alt -- just rely on <img> to be the fallback both 
>> for the alternate image and the @alt text. Leave @alt off <picture> 
>> altogether.
> 
> Just wanted to point out that what Adrian proposes here - <img> as the 
> element which takes care of the alternative text - is a variant (a 
> subset) of what Steve said: alternative text should be provided via 
> markup rather than via an attribute on the picture element.
> 
> If we say that <picture> should have img role, then we imply that 
> alternative text should be provided via an attribute. This means that 
> AT will pick the alternative text from the img element, as long as they 
> don't support picture. Fine. But it also means that at the moment when 
> picture support is enabled, they will suddenly start to take the 
> alternative text from another element - picture. This would work fine 
> as long as authors really do offer both - and the same content in both. 
> But it also means that, in other cases, the users will get a different 
> experience, based on whether the UA/AT supports - or not - the picture 
> element.
> -- 
> leif h silli
> 

It sounds like we may all be on the same page, now:

> After some thought, perhaps both cases are served by the fallback `img`—both the visual fallback for non-supporting browsers and for assistive tech. At the very least, users browsing by way of assistive technologies would be able to access the fallback `img` and associated `alt` attribute—something authors will likely specify anyway, and not something that can be easily omitted by mistake (at least, not without receiving a flurry of bug reports). At best, authors could be encouraged — but not necessarily required — to provide more rich fallback content: descriptive text beyond what is specified in `alt`, tabular data in the event that the `picture` represents an infographic, that sort of thing. This rich content could then, optionally, be visually hidden in non-`picture`-supporting browsers if desired.
> 
> This solution prevents duplication, avoids any additional attributes on `picture`, enhances the semantic meaning of the subject represented by the `picture` element, and provides an accessible minimum with no additional effort on the part of authors. It starts us from a seamlessly accessible baseline for authors—to my mind, a huge win—and provides us with greater potential for a11y enhancements.

— http://lists.w3.org/Archives/Public/public-respimg/2012Sep/0014.html

We would be omitting the role="img" from `picture`, all things considered.