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

Re: Feedback on Responsive Images Extension

From: Brett Jankord <bjankord@gmail.com>
Date: Tue, 4 Sep 2012 16:40:33 -0500
Message-ID: <CALgdvz8ciDMBMmt3G3B_+fCon-DQpZMosZzSRytigQUFm60tKQ@mail.gmail.com>
To: Andrew Kirkpatrick <akirkpat@adobe.com>
Cc: "public-respimg@w3.org" <public-respimg@w3.org>
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 <akirkpatrick@adobe.com>****
>
> http://twitter.com/awkawk****
>
> http://blogs.adobe.com/accessibility****
>
> ** **
>
Received on Tuesday, 4 September 2012 21:41:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 September 2012 21:41:04 GMT