Re: Feedback on Responsive Images Extension

On Sep 4, 2012, at 5:46 PM, Anselm Hannemann wrote:

> We had this discussion a couple of months ago in the W3C community group. I started it with the same intends as Andrew but after all it we came to the resolution that it's not what picture is thought for.
> If you define a picture-element you will most likely link to one image. This image crop/color/properties can vary but not the image meaning / content itself. If you want the meaning / content to change, just use a server-technology or JavaScript to properly change the source and alt. But it's no use-case for the picture-element.

Agreed: this is a case better solved by way of JavaScript or server-side UA detection. If the subject matter cannot be accurately described by a single `alt` attribute ( or additional descriptive markup, as discussed previously ), it is a disparate set of images and not a case I feel we should account for with `picture`.

> Hope you get my message as it's only a short abstract of the whole discussion.
> 
> -Anselm
> Am Dienstag, 4. September 2012 um 23:40 schrieb Brett Jankord:
> 
>> I believe displaying images based on OS type as described in the example below is well beyond the scope of the picture element. Though I do think you bring up a good point about a need for varying alt tags on source tags that display different art directed images as opposed to the same image at different sizes. My question is, are art directed images in the same picture element so different, that they would need different alt attributes, thinking primarily about a11y?
>> 
>> Regards,
>> 
>> Brett Jankord
>> 
>> On Tue, Sep 4, 2012 at 4:28 PM, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
>> I wrote some thoughts over the weekend but it seems that the conversation has moved in a few different directions – submitting anyway… J
>>  
>> This email is to provide feedback on the responsive images extension (http://dvcs.w3.org/hg/html-proposals/raw-file/tip/responsive-images/responsive-images.html#use-cases), specifically with regard to accessibility.
>>  
>> If the images are very similar in the difference picture’s <source> options, then the spec is sufficient.  However, if the media queries are used to provide substantially different art direction (yes, I know that this is cautioned against, but that won’t be sufficient to prevent issues), or if they are used alone or in conjunction with other scripting to determine what operating system or device the user is on, then it is easy to envision that the images might vary in very significant ways.  If, for example, the <picture> is part of an advertising block, the source for a user on iOS might be an advertisement for a new popular game for iPad/iPhone, but that the new popular game on Android or desktop windows could be very different.  Should authors use the capabilities to engage in browser or device sniffing, the spec doesn’t seem to provide the flexibility to allow the authors to maintain compliance with accessibility standards.  I’m not sure that merely codifying that this is not what <picture> is supposed to be used for is sufficient. 
>>  
>> To address this, I think the option of having alt on the <source> is needed.  The above example would be valid and appropriate for a set of like images, but something like the following is also needed:
>>  
>> <picture>
>>                 <source alt=”Angry Birds for iPad rated best game” media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
>>                 <source alt=”Voted best game for Android” srcset="small-1.jpg 1x, small-2.jpg 2x">
>>                 <img alt=”We have all your favorite games!” src="small-1.jpg">
>> </picture>
>>  
>> The processing rules would be that the alt value exposed to the accessibility API by the browser would be @alt on the picture (if present) + @alt on the utilized source (if present).  If neither existed then there would be a machine-detectable accessibility error.  The author would need to still monitor the quality of the alt and make sure that they choose the right approach, I believe that we  that we need this flexibility now and as the media queries become more sophisticated/capable these use-cases will become more prevalent. 
>>  
>> There may be another solution to this problem (authors offering different images based on device/browser-sniffing and having incorrect text alternatives as a result) but that is the problem that I’m concerned that we’ll see happening.
>>  
>> Thanks,
>> AWK
>>  
>> Andrew Kirkpatrick
>> Group Product Manager, Accessibility
>> Adobe Systems
>>  
>> akirkpat@adobe.com
>> http://twitter.com/awkawk
>> http://blogs.adobe.com/accessibility
>>  
>> 
>