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,
Rob