Re: unifying alternate content across embedded content element types

I accidentally pressed send.  My apologies.  I'll continue after the
quoted text.

On 7/15/07, Jon Barnett <jonbarnett@gmail.com> wrote:
> On 7/15/07, Robert Burns <rob@robburns.com> wrote:
> >
> > My contention (and this was a point I think Jon was making too), is
> > that when a textual equivalent describing the image is already in the> > surrounding  prose, it shouldn't be repeated for the @alt attribute.
>
> Yes, that's a part of what I was saying.
>
> > My proposal was something shorter that let's the user know what
> > meaning the image conveys in a way that matches it with the prose
> > available to all users.
>
> Sorry for my ambiguous use of the word "alternate".  By "equivalent"
> != "alternate", I meant that "equivalent" is a subset of "alternate".
>
> Sometimes alternate content is used as a drop-in equivalent:
> Completely replacing the image with the equivalent content doesn't
> change the meaning of the document
>
> Sometimes alternate content is used as a description of the media:
> Complete replacing the image with the descriptive (alternate) content
> doesn't make sense unless you let the user know that something is
> missing.
>
> And my proposal is that the same markup used to provide equivalent
> (alternate) content shouldn't be the same as the markup used to
> descriptive (alternate) content.
>
> With relation to this thread, I meant that I don't like <object alt>
> as a mechanism for "short alternative" content.  Would it be an
> equivalent to the <object>, or would it be a description of the
> object?  I think it has too much potential for misuse in the same way
> <img alt> is being misused.  (And the fact that professionals can
> disagree on <img alt> tell me that it's not defined well enough)
>
> <p>A paragraph about Fluffy's kittenhood...
> <img src="fluffy-yarn.jpg" alt="">
> <p>On Saturday, Fluffy was playing with a ball of red yarn in my
> living room.  It was quite funny.
>
> In this context @alt isn't necessary.
>
> <p>A paragraph about Fluffy's kittenhood...
> <img src="fluffy-yarn.jpg" alt="On Saturday, Fluffy was playing with a
> ball of red yarn in my living room.  It was quite funny.">
> <!-- no following paragraph -->
>
> In this context, @alt is necessary to provide equivalent content for
> the image.  Completely replacing the image with the @alt content
> doesn't change the meaning of the document.
>

<object data="abbott-costello.mpg" title="Who's on first?">
 <object data="abbott-costello.ogg"></object>
</object>

Here, the outer <object> has fallback to another <object>.  That is
another case of equivalent content - providing equivalent media in
another format.  But what should the contents of the inner <object>
be?

I contend that it should be the full transcript of the "Who's on
first" sketch.  That would also be equivalent content.  I honestly
believe this will be rare - authors will rarely provide a truly
/equivalent/ textual alternative for a video.

Otherwise, it should be a short (possibly rich) description of the
sketch, with possibly a link to more information.  But a description
of the content is not the same as an equivalent to the content, so the
UA should let the user know that the media is missing, why, and
possibly provide a link to the missing media. (The user could be
sighted, but not see the media for other reasons.)

These two possible textual "alternatives" should have different markup
for a couple reasons:
- So authors don't confuse "equivalent" content with "descriptive"
content the way they do now (I would still like to know if there's a
decent way I can gather statistics on how "alternate content" really
is used on the web.)
- So UAs can present "equivalent" content as a drop-in replacement for
the media, but "descriptive" content as an accessible fallback with a
note that certain media are missing.

Hope that better says what I meant.

I really think <img> is useless for images that are "worth a thousand
words", so I'd prefer to use <object> better than try to fix img/@alt
and img/@longdesc

--
Jon Barnett

Received on Sunday, 15 July 2007 14:06:14 UTC