RE: Adaptive Image Element Proposal

We're not at #1 yet (unless "future" means 5 minutes after you sent that note) and we are still sorting out the long text description. As it is, #1 doesn't address the short text description (think @alt vs @longdesc).

Depending on how far out that future is, there may still be devices that don't understand <picture> (look at how long IE6 has lasted in the wild).

For #2 you're discussing the long text description, which to me is outside of the scope of a discussion of a short text description (what we currently know as @alt).

In #2 you're not discussing the short text description and you still have @alt on the <img> and not on <picture>, which is the approach I am advocating and which I believe Mat has said he is planning to support in a revision.

I'm just trying to stay focused on the @alt. The @longdesc-level discussion is still percolating in my head.


> From: John Albin Wilkins [mailto:john@albin.net]
> 
> 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:29:46 UTC