Re: unifying alternate content across embedded content element types

Hi Jon,

On Jul 14, 2007, at 8:55 PM, Jon Barnett wrote:

> On 7/14/07, Sander Tekelenburg <st@isoc.nl> wrote:
> But context !=
> alternates/equivalents/fallback. Context is context, and is exactly  
> the
> same/exactly as useful for whichever equivalent the user happens to  
> access.
>
> I hope I'm not beating a dead horse here...
>
> context is often equal to fallback. There are cases where the  
> context and the fallback would be exactly the same, and then the  
> fallback would be unnecessary and redundant.  But, equivalent !=  
> alternate

Could you say more about equivalent != alternate? My understanding is  
that some would like to use the term "equivalent" instead of  
"alternate" to underscore the need that the alternate content should  
be be equivalent in the sense that it should provide someone with  
everything they need to understand the document in the event the  
primary content is missing or unusable (or not fully usable in the  
case of partial blindness, color blindness or cognitive disability  
for instance) in any way for a particular user.

The term fallback gets used here too because, as I understand it, the  
author delineates a hierarchy of content so that the primary content  
is preferred by the author over the various ordered fallbacks. The  
authors preferred ordering interacts with the user's preferred  
content and content consumption abilities (based both on technology  
and physical/cognitive abilities). Is there something different you  
mean when you say that equivalent != alternate? Also does my use of  
fallback jibe with yours?

> In other words, "fallback" is sometimes equivalent of content:
> - "PDF" instead of a PDF logo

Perhaps "logo" instead of "PDF"? Or no do you mean "PDF Icon" for an  
image of an acrobat file?

> - equivalent media, but a different format when the preferred  
> format is unsupported
> - the textual transcript of a video

Sure, as I elaborated above here its equivalent (or one should strive  
for equivalent) in the sense that a user unable to consume the  
primary content will still be able follow the meaning of the document.

> - any other case where completely replacing the media object with  
> the fallback does not change the meaning of the document

Agree. Incidentally, these equivalents can sometimes (potentially?)  
be handled through content negotiation. In other words: <object  
data='myfile'>fallback</object> could potentially be any one of  
several formats. In contrast, it could instead be done with nested  
<object> elements (or another embedded content element).

> and sometimes "fallback" is a description of a content:
> - a description of a photo of the Grand Canyon
> - a description of a video
> - any other case where the "fallback" seems out of place without a  
> note that certain media are missing

Or unusable because of available technology, platform, or disability.

> I think better defining the markup for a semantic "equivalent" vs.  
> a semantic "alternate" is more useful than defining markup for  
> "long" vs. "short".

So is this in response to shortening the @alt attribute. Or are you  
responding to the idea of adding the @alt attribute as a short  
description to other embedded content elements? I'm trying to follow  
this thread, but I'm not sure what you're responding to here exactly.  
For example, would you say that <img>  provides the @alt attribute  
for alternate content and the @longdesc attribute for equivalent?

> If those semantics are clearly defined, authors will have a better  
> chance at making more accessible content, and UAs will have a  
> better chance at presenting it appropriately.  I think this is more  
> useful than creating more ambiguously defined markup that authors  
> and UAs will treat incorrectly.

Is this in response to <picture>? I could understand that. It would  
be a terrible disappointment to specify a new <picture> element only  
to have implemented in a messed up non-interoperable way.

> Are the contents of <object> an equivalent or a description?  Both,  
> in certain cases?

Agreed. The description could even be a textual string based  
description or an audio file description.

> Does <object> need a <caption> descendant that serves as  
> descriptive fallback instead of equivalent fallback?

Here I think I don't understand precisely because I don't know how  
you're distinguishing between descriptive fallback and equivalent  
fallback. Perhaps this has nothing to do with what you're saying, but  
the HTML5 draft does have a <legend> element  to create captions  
inside a <figure> element. However, there its not used for fallback,  
but for contextual descriptive text rendered (visually, aurally or  
tactilely) alongside the embedded content (or whichever fallback  
content level reached).

> If [<object>] had [a caption element], UAs could treat it  
> differently from equivalent fallback by noting that media is  
> missing possibly noting why ( e.g. "Failed to load example.mpg",  
> "Link to example.mpg")

Does that mean you're thinking of caption as a linking mechanism?  
Right now a group of nested objects could already concluded at the  
lowest depth with <object data='MyLastChanceMedia'> Failed to load ,a  
href='example.mpg'>example.mpg</a></object>.

Anyway, I'm just trying to understand what you're saying. I think  
there's probably much less disagreement here than it appears on the  
surface. If we can somehow synchronize our terms, I think we make  
more progress.

Take care,
Rob