W3C home > Mailing lists > Public > public-html@w3.org > September 2012

Re: Adaptive Image Element Proposal

From: Mathew Marquis <mat@matmarquis.com>
Date: Tue, 4 Sep 2012 13:47:22 -0400
Cc: Peter Winnberg <peter.winnberg@gmail.com>, Steve Faulkner <faulkner.steve@gmail.com>, HTML WG <public-html@w3.org>, "public-respimg@w3.org" <public-respimg@w3.org>
Message-Id: <E5DDF010-0425-46F2-B2B8-C54F6876F2EC@matmarquis.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Based on the feedback we’ve received in both this thread and a quick informal poll of developer preference in the respimg CG’s mailing list ( archived here: http://lists.w3.org/Archives/Public/public-respimg/2012Aug/0045.html ), it seems that while it’s generally accepted that the `aria-describedby` approach is the more elegant of the two approaches, the duplicated `alt` attribute is the more intuitive. It also stands to have the `alt` information available to the widest number of users, where `aria-describedby` may not be available in all contexts. It’s unfortunate, but our obligation is to the end users first and foremost.

I think our best bet is to require that authors specify an `alt` attribute on both `picture` and the fallback `img`. There has been a great deal of discussion along these lines to support that decision, as outlined in Laura’s incredibly helpful message here: http://lists.w3.org/Archives/Public/public-respimg/2012Aug/0047.html

I am still curious about the viability of allowing an `alt` specified on the fallback `img` to “bubble up” to the parent `picture` element — if that should be possible, I think it would be ideal if we could mention that specifying an `alt` on the fallback `img` applicable to the parent `picture` is also a valid approach.


> Steve Faulkner, Fri, 31 Aug 2012 20:14:06 +0100:
> 
>> 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>
> 
> So, just to be 100%: Based on how JAWS + Firefox 13+ handle the canvas 
> element[1], then AT users would experience the picture element the 
> following way::
> 
> 1. the picture element would itself not be announced (unless
>   authors added a role (e.g. role=img) to the picture element) and
> 2. in case there were no <img> element in the fallback, then AT users 
>   would not be told that there was any image here.
> 
> So, they would not experience it.
> 
> (Strictly speaking, and despite the canvas behavior, the AT *could*
> probably announce the picture — e.g. it could say ‘Picture!’. But
> if so, if there could perhaps be confusion e.g. if it found <img>
> element inside the picture.)

Fortunately (in a sense), this is a fundamentally broken scenario even outside the realm of a11y: without specifying a fallback `img`, no user in an unsupported browser would know an image existed. I think this is a fairly unlikely situation, at least for a long time yet — it wouldn’t be an “out of sight, out of mind” sort of error on the part of a careless author.

On a separate note: I do think `role="img"` should be an essential part of any `picture` polyfill. Steve, are you okay with my copying your post above and filing an issue on Picturefill ( https://github.com/scottjehl/picturefill/tree/div-markup-currentprop ), so I can address this as soon as possible?

Thanks,
-M
Received on Tuesday, 4 September 2012 17:47:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:34 UTC