Re: Adaptive Image Element Proposal

On Sep 4, 2012, at 3:38 PM, Kornel Lesiński wrote:

> On Fri, 31 Aug 2012 02:31:45 +0100, Leif Halvard Silli <xn--mlform-iua@målform.no> wrote:
> 
>> By the way: How is fallback supposed to be working in the picture
>> element?  The draft points to HTML5 with regard to a definition of
>> fallback. [1] However, in HTML5, there are at least 3 fallback models:
>> 
>>  * img: the element retains its role when we see the fallback
>>    * video/audio: we don't get fallback, even if the media format
>>      is unsupported.
>>    * object: if fallback steps in, then the object looses its default
>>      "role", and focus is given to the fallback instead.
>> 
>> One could say, that as long as picture element is not supported, then
>> it is the object model that is operative. (And the duplicate alt model
>> works OK - from users point of view - in that scenario.) But how should
>> an without support for the mime type of the image react?
> 
> I think it should be modelled after <object>. If the image cannot be displayed for any reason (invalid mime, bad data, 404, user preference) then the fallback/alt content should be displayed instead.
> 
> 
> BTW: it appears to me that there's a design pattern in HTML that <picture alt> doesn't fit into:
> 
> Void elements use alt:
> <img alt="alt" /> <input type=image alt="alt" />
> 
> But non-void elements use content:
> <object>alt</object> <iframe>alt</iframe> <canvas>alt</canvas> <video>alt</video>
> 
> (while not all of them have fallback behaving the same way, the markup pattern is the same)
> 
> So a non-void <picture> element with an alt attribute for fallback would be an odd one. Since it's non-void, the right place for fallback/alt is inside the element.

This is an excellent point. 

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.


> 
> -- 
> regards, Kornel
>

Received on Tuesday, 4 September 2012 19:54:09 UTC