RE: Adaptive Image Element Proposal

#2 is a rather verbose solution to something that can be, and should be, handled by the JS engine's implementation. As this is a spec for both devs & browser manufacturers, it follows that the guidelines for when to use which description should be baked in, and not require CSS styling.

-----Original Message-----
From: John Albin Wilkins [mailto:john@albin.net] 
Sent: Thursday, September 06, 2012 12:35 PM
To: Konopacki, Daniel
Cc: Anselm Hannemann; Adrian Roselli; Leif Halvard Silli; Laura Carlson; Mathew Marquis; Peter Winnberg; Steve Faulkner; HTML WG; public-respimg@w3.org
Subject: Re: Adaptive Image Element Proposal

I believe the contents of the picture tag (whatever they are) should be the alternative content if the picture tag isn't supported by a browser; I don't think we need an alt tag anywhere in the picture element, nor do we need to REQUIRE an img tag with an alt attribute. Here's my thoughts:

1. In the future, when all browsers support the picture element: The children elements of the picture element will be the alternative content when the image specified by the picture element can't be displayed. (This can be any HTML.) No need for a fallback img tag or any alt attribute.

<picture>
  Longer alternate content
</picture>

2. In the meantime, when not all browsers support picture element: Ditto as above, but we recommend a fallback img tag IN ADDITION to other alternative content. Something like this:

<picture>
  <img alt="short description" class="picture-alt-img">
  <div class="picture-alt">Longer alternate content</div> </picture>

To prevent the "double alt text" problem, we can leverage the "element-invisible" styling (best described by this article: http://snook.ca/archives/html_and_css/hiding-content-for-accessibility ). The element-invisible styling gives us the ability to make things invisible to sighted users, but still accessible to screen readers, etc.

So we could use that syling on the "picture-alt" wrapper to alleviate problems. It might require some JS to check if a image resource has been loaded into the img tag or not; I'm not sure.

If it wasn't 3:30am here in Taiwan I would try to work out all the edge cases. But it's beyond my ability to be that coherent in a multi-step discussion.

But wouldn't something like that be future proof as well as accessible to all the right people?

 - JohnAlbin


On Sep 7, 2012, at 2:37 AM, "Konopacki, Daniel" <Daniel.Konopacki@disney.com> wrote:

> I agree with Anselm's assessment here. If there were either @alt or @alt equivalent for <picture>, I feel that devs could be given an option. For brevity's sake, a simple example:
> 
> Example 1:
> <picture>
>   <img src="file.jpg" alt="Some description" /> </picture>
> 
> Example 2:
> <picture alt="Some description">
>   <img src="file.jpg" alt="Some description" /> </picture>
> 
> In the first example we leave off the @alt attribute from the <picture> tag. Browsers requiring a short text description would then fallback to the <img> @alt value. In the second example, however, there are two @alt attributes. For browsers supporting <picture>, they utilize the <picture> tag's @alt value, while the others will fallback to the <img> @alt value. This both allows devs to write the markup in a more simplistic way (Example 1) and provides a path to future deployments (Example 2 allows the complete omission of <img>).
> 
> From: Anselm Hannemann <info@anselm-hannemann.com>
> Date: Thursday, September 6, 2012 11:27 AM
> To: Adrian Roselli <Roselli@algonquinstudios.com>
> Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Laura 
> Carlson <laura.lee.carlson@gmail.com>, Mathew Marquis 
> <mat@matmarquis.com>, 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>
> Subject: Re: Adaptive Image Element Proposal
> Resent-From: <public-respimg@w3.org>
> Resent-Date: Thursday, September 6, 2012 11:27 AM
> 
> Yes, you miss a point:
> In 10-15 years we are not needing the img-element anymore. But then it would be required by spec.
> This is what I fear of.
> 
> -Anselm
> 
> Am Donnerstag, 6. September 2012 um 20:22 schrieb Adrian Roselli:
> 
>>> From: Anselm Hannemann [mailto:info@anselm-hannemann.com]
>>> 
>>>> Hi Lief,
>>>>> Needless complexity: The complexity is related to lack of support 
>>>>> for <picture>
>>>> 
>>>> That's right. That is why Mat will be changing the draft spec to 
>>>> use <img> with alt for the short text alternative not <picture> and 
>>>> a new text alternative method.
>>>> http://lists.w3.org/Archives/Public/public-html/2012Sep/0016.html
>>> What? Why do we rely on the img-fallback(!) now?
>>> I always thought the img-element is not required but optional (for 
>>> fallback methods). If we now rely on img for alt-attribute this 
>>> would require to alway have an img-tag inside of the picture-tag. This is what I call complexity.
>>> It might be handier to not have to specify 2 alt-attribute-values 
>>> but longterm it is bad spec. The only two valid strategies would be 
>>> the long version inside the picture-element or the alt-attribute for the picture-element.
>>> 
>>> Sorry, I speak for my own but this is a longterm consideration.
>> 
>> <picture> needs a fallback of some sort otherwise users in current and older browsers won't see any image at all.
>> 
>> <img> allows authors to specify a fallback image for those users who can see the image but don't have a <picture>-capable browser.
>> 
>> For users who simply cannot see images (whether vision impairment or unfortunate connection), there still needs to be a text fallback somewhere in there. If <img> will be part of <picture> and <img> already has rules for @alt, then requiring @alt on <picture> just creates more complexity (room for error, mismatches, etc). Therefore, just lean on @alt from the <img> that will already be there.
>> 
>> With this method the only complexity above what web developers do today is adding the <picture> and its children. And that additional complexity will only be there if a developer wants to use this new feature.
>> 
>> This only addresses the short text alternative, but I think that's the one you are questioning.
>> 
>> Is there a piece I am missing in my (attempted) logic?
>

Received on Thursday, 6 September 2012 20:23:36 UTC