Re: Improving alt (was handling fallback content for still images)

In reply to, Robert Burns <rob@robburns.com> who wrote on 7/7/07  
[with corrected longdesc value]:

> <figure>
> <video src="media/gw.ogg">
>   <img longdesc='#gw' src="media/gw.jpg" alt="">
> <longdesc id='gw'>Because of his role as  the Commander in Chief of
> American forces
> in the  Revolutionary War, and, later, the first President of the
> United States,  George Washington is often called the &quot;Father of
> his Country&quot;.</longdesc>
> </video>
> <legend>George Washington</legend>
> </figure>

On Jul 7, 2007, at 9:10 PM, Ben Boyle wrote:
> Yes, that is similar.
>
> One issue I see is that the longdesc is associated with the img
> element, but not the video element.

Well it is associated with <video> in the sense that it is  
hierarchically two fallbacks away from <video. That is the UA, by  
default, displays the embedded content of the video referenced by the  
<video> element. If it cannot, then the UA displays the embedded  
content  image referenced by the <img> element. If it cannot do that,  
then the UA displays the content of the <longdesc> element. Whichever  
alternate the UA displays, it does so within the bounds of the  
<figure> element along along with the caption in the <legend>  
element. Also, the other advantage of a new <longdesc> element is  
that it would work within a <figure> OR among inline-level content  
that's not inside a <figure> element.

> Perhaps @longdesc belongs on
> <figure> but then I think the contents of the figure would suffice and
> the id/idref could be redundant.

No, I don't think that @longdesc goes with <figure>. The idea is to  
provide a standard container for the document fragment that the  
@longdesc attribute points to. Ideally, this wouldn't be necessary if  
we could just place that document fragment within the <img> element  
itself. However, it seems the next best thing to simply recommend  
authors place a next sibling <longdesc> element, immediately after  
any <img> or <embed> element to contain the alternate fallback for  
those two elements. We also recommend UAs only display the contents  
of <longdesc> element as fallback if the <img> or <embed> cannot be  
displayed.

> "figure" can already contain:
> 1. embedded content element (which can fallback)

Except for two embedded content elements: <img> and <embed> The  
<figure> element can deal with fallback until the author needs to use  
on of those two elements that don't readily support fallback.

> 2. caption using <legend>

The legend element would work alongside the primary or fallback  
content regardless of how that's handled.

> I'd like to extend this to say it can include other elements (block
> level probably?) which get treated as "contextual information related
> to the figure". That's explicit enough for me, and pretty easy to
> author (and probably what is meant, if an author chucks extra stuff
> within <figure>)

I'm not clear about what you mean here. Are you saying that the non- 
embedded contents of a <figure> should be treated as fallback for the  
primary embedded content within the <figure>.

> We could add in @longdesc and a new element like <longdesc> but I
> don't see that it adds much and being more proscriptive is probably an
> unnecessary challenge for authors.

I''m not sure what you mean by "being more proscriptive". The  
<longdesc> element simply adds to what an author can do. I'm not  
suggesting that authors not be allowed to use the <img longdesc="">  
in ways their already accustomed to.

Take care,
Rob

Received on Sunday, 8 July 2007 03:31:42 UTC