Re: the market hasn't spoken - it hasn't bothered to listened [was Re: fear of "invisible metadata"]

On Jun 26, 2007, at 11:25 AM, Smylers wrote:

> Robert Burns writes:
>> Perhaps I should provide an alternative example just to illustrate
>> what I'm trying to say.
> Thanks -- that's really useful.
>> <object
>> 	data="foo.mpeg"
>> 	alt="My kitten fluffy playing with yarn."
>> 	title="fluffy playing with yarn"
>>> Fluffy, still only a few inches tall, is playing with a red ball
>> of yarn that has to 3 times her size. She has just fallen on her back
>> and it looks like the ball of yarn is crushing her. But she's really
>> just having fun. </object>
>> Do the two character strings look different to you in this example?
> Yes, those are different.
> But it isn't clear to me under what circumstances having both these
> alternative representations available is advantageous.  I can think of
> contexts in which either one of them may be preferable -- for  
> example if
> the text farther down the page makes a reference to the "crushing"/fun
> incident, then the longer of the above explanations will be needed in
> order for the text to make sense to those who haven't seen the
> video[*0], whereas if the video is merely an example of your kitten
> doing something and the particular action isn't relevant then the
> shorter one would be more appropriate.
> But either the detail is pertinent or it isn't.  I'm not sure how  
> if two
> versions available the browser should pick which one to display to the
> reader.  Or, if the reader is presented with a choice how she'd know
> which one to go for.

Well, I was adding the @title attribute to push the discussion a bit.  
As for @alt, it may bet that an aural browser user might want to hear  
a little snippet like that @alt attribute before deciding what order  
to consume the embedded elements in. The @title attribute might work  
in place of that. Again, I'm just trying to get us to collectively  
address these things. Once more the things I think we should be doing:

1) deprecating (dropping) <img> and <embed> and with them the  
@longdesc attribute that is  included only because these elements do  
not properly support fallback like all other embedded content  
elements. Instead of the <embed> element we would promote the  
<object>, <video>, <audio>, etc embedded content elements. Instead of  
the <img> element we would promote UA support and author adoption of  
a new <still> (or <picture> or <pic>, etc.) element that supports  
fallback content.

2) decide whether the inclusion of @title, @alt, and @longdesc on  
<img> is something that should be extended to the other embedded  
content elements. In other words images have a @title attribute an  
@alt attribute as well as a @longdesc attribute that points to a  
document fragment servving as a substitute for genuine fallback  
content that all of the other embedded content elements have (with  
the exception of the <embed> element which I think we should treat  
the same as <img>..

3) Consider whether non-visual browser users have become accustomed  
to @alt and consider whether it might be needed (optionally or  
required) for all embedded content elements. Or whether the @title  
attribute could serve that purpose instead (again leaving <img> alone  
since it would become deprecated along with <embed>).

>   [*0]  Actually I quibble with your "But she's really just having  
> fun."
>   If from the video it _looks_ like she's being crushed then anybody
>   watching the video will be unaware that it was actually fun -- those
>   who've read the "alternative" content will be better informed  
> than the
>   video-watchers!  So that fails as a strict alternative.  But this is
>   largely beside the point: I'm sure we could come up with a similar
>   example which had no such quibble; my main point above would still
>   stand.

Well perhaps the viewers of the video might be able to tell that the  
cat was actually having fun. This might not come across with the  
fallback content description I gave without the last sentence.  
Perhaps we should require aural browsers to somehow enunciate  
emoticons :-). Of course this would leave the viewers of the fallback  
<still> image concerned about the cats fait :-).

Take care,

Received on Tuesday, 26 June 2007 17:02:03 UTC