unifying alternate content across embedded content element types

I started a new thread and subject heading, because this is really a  
separate issue than the one Sander first raised.

On Jul 6, 2007, at 3:31 PM, Sander Tekelenburg wrote:
>
> At 15:53 -0500 UTC, on 2007-07-05, Robert Burns wrote:
>
>> I present this example because I'm wondering whether we need @alt in
>> addition to @title?
>
> We do (as long as we're stuck with img). @alt and @title have very  
> different
> semantics.
>
> Don't let yourself be fooled by the unfortunate current situation  
> that most
> popular UAs present both through the exact same mechanism. That's  
> just an
> implementation mistake. Even amongst the specialists in this WG it  
> causes a
> lot of confusion, so it's obvious that this needs to be fixed --  
> that the
> spec will have to require that UAs present @alt different from @title.

Let me emphasize the opposing side of the argument I was trying to  
make just to see how you respond to that. This is somewhat  
independent of how current UAs present this or how we may want to  
recommend UAs present alternate in the future. The @alt attribute is  
only available for <img>. Is it just because @longdesc is so  
difficult to work with? Or are there (now) other reasons to separate  
alternatives into short and brief versus long and richly semantic.  
Because if there are other reasons than perhaps we need to add @alt  
to all the other embedded content elements too.

To reiterate the list of alternate information available for non-text  
media:

1) media-file-specific fallback content / accessibility hooks /  
textual metadata
2) the surrounding prose
3) the <legend>
4) alternate (fallback) content
	a)  the rich fallback (sometimes through @longdesc otherwise through  
the element's contents)
	b) @alt (currently on <img> only)
	c) @title (on everything embedded)

I rearranged the list because I think, as part of best practice, we  
may want to recommend authors follow something like this ordering  
(and UAs, even visual UAs, make the content available as in your  
proposal). That is 1) to the extent embedded non-text media can  
include alternate / fallback content, according to its own format  
specification, that makes the content highly reusable in an  
accessibility (semi-)friendly way. This could be close captioning or  
audio description channel for a video file. (It could merely be a  
textual description or textual keywords for a image/ping file).

2) The surrounding prose should provide description that  
contextualizes the non-text media content that is useful for both  
sighted and vision-impaired or aural-impaired users; though  
expressing that relation between the embedded content and the  
description may be difficult (perhaps we need another attribute for  
embedded content to point to the document fragment or start and end  
of descriptive prose about the embedded content).

3) Similar to the surrounding prose, the <lgegend> element provides  
descriptive context for the non-text media for all users. Here the  
relation between the embedded content and the legend's text is  
clearly structured.

4) If after providing everything  prior in the list, an author  
determines the content still needs additional alternate content for  
any targeted accessibility audiences, the author should use these  
alternate / fallback mechanisms.
	a) rich fallback content either through @longdesc or through the  
element's contents (as the case may be)
	b) providing a brief but descriptive contextual comment value for  
the @alt attribute on an <img> element or in the @title attribute on  
other embedded media elements.

So again, why do we have an @alt on <img>, but not on the other  
embedded content elements? It may have started out because of the  
difficulty of using @longdesc, but it has evolved to be used for  
another purpose. Is it therefore worth it to preserve that  
distinction on other embedded content elements?

>> Does it provide something necessary that longdesc
>> does not.
>
> Yes. Both @alt and @longdesc are about *alternatives*  to the  
> image. @title
> is for a certain type of *additional* information.

Would you say then that @title, in providing "additional"  
information,, sufficiently fulfills the needs for brief alternate  
description on all of the other embedded content elements (i.e.,  
other than <img>)?

I hope that by taking the opposite tack of my first email, it is  
clearer what I'm trying to say. That is I'm not advocating for  
replacing @alt with @title. Rather, I'm trying to unify, as much as  
possible, how we use these various embedded content elements. Earlier  
I had leaned more in the direction of using @title instead of @alt on  
<img>, since we don't have @alt on the other embedded content  
elements. Here, I'm stressing the possibility of adding @alt tot he  
other embedded content elements under the grounds that if @alt has  
now become a separate purpose than the semantically rich alternate  
content, then it will also be needed for that purpose on any embedded  
content (whether <img> or not).

Take care,
Rob

Received on Friday, 6 July 2007 22:26:35 UTC