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

On Jul 8, 2007, at 4:07 AM, Ben Boyle wrote:

>
>> > 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>.
>
> No, not fallback. It should always be rendered alongside the
> video/image/etc. UAs don't need to do anything special. AT could use
> it for richer accessibility: e.g. it's contextual information within
> the page that relates to the embedded content (of course it relates,
> it's part of the figure).
>
> It's kind of like an implied longdesc pointing at a sibling element
> (visible to all).

Isn't that what <legend> is for? That's my understanding. It's only  
supposed to contain inline level, content, but perhaps it should  
permit more. I would imagine that most publishers do not necessarily  
limit captions on figures to inline level content. I would think it  
should be inline or block, but not both (perhaps the same content  
model for table > caption too).

>>>  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.
>
> We could do this:
>
> <figure>
> <img ... longdesc="#gw">
> <div id="gw">
> </div>
> </figure>
>
> which is aligned with your suggestion. My suggestion is to simplify  
> that to:
>
> <figure>
> <img ...>
> <div>
> </div>
> </figure>
>
> i.e. not require @longdesc and a matching @id within the <figure>
>
> Easier for authors. Perhaps not quite as explicit in the markup. But
> if we define HTML 5 to work that way, then it would be explicit.
> @longdesc is more flexible in that it allows you to reference content
> outside the <figure> (indeed, outside the current document).
>
> These are just alternatives to consider. I'm keen on "easier to  
> author".

Now, I think I understand what you're looking for. However, I think  
expanding <legend> to support block level content would be a better  
solution. To me, that is the natural way to use <figure>: to have  
embedded content and a caption of any length. That caption (<.egend>)  
should also allow semantically rich content like:

<figure>
<legend><h1>Riding the rapids</h1> At this point in the trip, the  
team found itself riding the rapids of … </legend>
<video src='avideo' ></video>
</figure>

Would this accomplish what you're looking for. It would mean that  
<figure> would typically have two child nodes: 1) an embedded content  
element and 2) a legend content element. Each of those, in turn,  
would have any number of descendant nodes: embedded content elements  
for fallback; and 2) legend elements for semantically rich  
description of the embedded content.

The legend is displayed regardless of how deep the fallback content  
goes.  However, the current draft says that if no fallback content  
can be supported the entire figure is ignored (so then the legend  
would be discarded).

This is a different issue than I was trying to solve with a  
<longdesc> element. In that case I was trying to provide an easy  
container for authors to sue to point to fallback with the @longdesc  
attribute.

Take care,
Rob

Received on Sunday, 8 July 2007 21:41:52 UTC