Re: figures, images and fallback content (was: fear of "invisible metadata")

On Jun 23, 2007, at 2:00 AM, Ben Boyle wrote:

>
>> > [1] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?
>> > rev=1.78#figure
>>
>> I'm having trouble reading the draft in this way. I would agree with
>> you 100% that the aural browser should have access to the caption/
>> legend and the alt. However, I can't tell where in the draft you see
>> the opposite.
>
> Well I could be wrong. Let's see if we can figure out this spec :)
>
> http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html#the- 
> figure
> We've got a new element: <figure>
> It can contain: <legend> + "embedded content" (I'm not sure exactly
> which elements qualify as "embedded content" but for now let us say
> <img> definitely does).
>
> <figure>
> <legend>This is an image caption</legend>
> <img src="something.png" alt="alt text here">
> </figure>
>
> Now go read the spec again, particularly what follows from "If the
> embedded content cannot be used, then, for the purposes of
> establishing what the figure element represents:" ... the points
> indicate what happens when the image (embedded content) cannot be used
> (which I believe applies for screen readers, amongst other cases).
>
> We need to know about "fallback content" at the moment.  
> Specifically for images:
> "the value of the alt attribute is the img element's fallback  
> content."
> http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html#img
>
> So, when an img can't be used, we use the alt attribute. All good.
>
> Now let's go back to the fallback rules for <figure>:
> 1. If the embedded content's fallback content is a single embedded
> content element ...
> This doesn't apply to <img>. The fallback for <img> is @alt which is
> not "a single embedded content element". (This rule useful for other
> embedded content elements). Moving on ...
>
> 2. If the embedded content's fallback is nothing ...
> OK, this can apply to images, specfically when alt="" or alt is  
> omitted.
> ... The entire figure element (including the caption, if any) must  
> be ignored.
> Therefore, ignore <figure> (including <legend>), because there is no
> alternative.
>
> 3. If the embedded content's fallback is inline-level content ...
> This applies when there is an alt attribute with a text value.
> ... The entire figure element (including the caption, if any) must be
> treated as being a single paragraph with that inline-level content as
> its content.
> Therefore consider <figure> ... </figure> replaced by a "paragraph"
> containing the alt text (and not the <legend> which is now
> suppressed). I guess this means <figure>alt text here</figure>
> although it might mean <p>alt text here</p> ... I find the spec
> ambiguous about "paragraph" here:
> http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html#paragraph
>
> 4. Otherwise ...
> This doesn't apply to <img> either. They either have alt text or they
> don't, so the previous two options cater to all possible scenarios
> (again, useful for elements other than <img>)
>
> I'm not sure if this will make things clearer... should I do up an  
> example?
> It still seems clear to me that the legend will be suppressed when
> fallback is applied.


I can see how the draft could be read that way. Its also possible  
that the @alt attribute isn't being included with fallback content. I  
could see it being considered by fallback in a sense or not. However,  
you definitely raise some issues that need clarification in the next  
draft.

I also think this raises the issue of @alt for any media / embedded  
content elements. It also raises the particular problems with <img>  
and <embed> in that they are defined as canonically empty and  
therefore make fallback difficult. My view is that:

1) both <embed> and <img> should  be deprecated in favor of <object>,  
<image> (added) and other media / embeded content elements
2) both <embed> and <img> should have a @longdescr attribute (despite  
being deprecated as a stop-gab measure)
3) we should include the @alt attribute for all media / embedded  
content elements and work out / clarify the @alt attribute's  
relationship to @title for authors and implementors (with processing  
algorithms and UI recommendations)
4) <legend> should be renamed <caption> (unless we cannot work out  
the processing issues with table which its not at all clear is a show- 
stopper) Calling it legend adds undue complexity to the language  
since <legend> is intended to relate to embedded content elements in  
the same way that <captioN> relates to <table>
5) make it clear (per Ben's suggestion) that the <caption> (or  
<legend>) equally applies the main element as well as to all of its  
fallback fragments.

Again, I think these assistive technology blunders need to be dealt  
with before anything is made public from this working group.

Take care,
Rob

Received on Saturday, 23 June 2007 20:53:26 UTC