Re: Adaptive Image Element Proposal

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