W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: Marking up alternative versions of content

From: Jason White <jason@jasonjgw.net>
Date: Sat, 4 Aug 2007 11:23:29 +1000
To: public-html@w3.org
Message-ID: <20070804012329.GA6301@jdc.local>

On Fri, Aug 03, 2007 at 07:07:12PM +0200, Sander Tekelenburg wrote:
> Ah, right. I get it. <alt for=idref>equivalent</alt> would then remove the
> need for the equiv attribute that I suggested. It would also not need @rel,
> and thus remove the need to refine the definition of @rel. (Or am I
> overlooking something?)

No, I don't think you're overlooking anything; @rel is not needed in this
proposal.
> 
> Yeah, that would seem to be easier to author and easier to implement.
> 
> A potential issue: thinking about the different types of situations in which
> publishing of equivalents would need to be possibe, it would seem to be
> necessary to allow <alt> as both block and inline. (Or not? I don't really
> 'see' that yet.)

For flexibility, it would be best to allow it in both block-level and inline
contexts, with a transparent content model, I think.
> 
> [...]
> 
> > With all three proposals, there arises a need to specify how a user agent
> > should treat multiple idrefs referring to the same element. As you suggested
> > elsewhere, a type attribute could be introduced to distinguish different
> > alternatives to the same media element.
> 
> Right. But unless I'm mistaken, type is currently only for MIME types. It
> might not be wise to start allowing other sorts of values. Or would
> "application/video+caption" and such be appropriate? I don't know enough
> about MIME types to judge that.

I agree that MIMe types may be insufficiently expressive for this purpose.
Furthermore, if one media element is used as an alternative to another, the
task of deciding whether the alternative can be retrieved and rendered is the
same as for the original, so I don't think additional resource type
information needs to be disclosed in the proposed <alt> element.
> 
> > All of the above proposals are
> > compatible with a policy of allowing only one alternative to be associated
> > with any given media element (the first alternative, in document tree order,
> > would be treated as a fallback, with the remainder of such alternatives being
> > ignored, i.e., as though @irrelevant were in effect).
> 
> I can't follow. Why would multiple <alt> elements referring to the same id
> through @for, not be possible?

They are possible, and indeed I would prefer that they be supported; but I'm
open to a more restrictive proposal that enforces a "one alternative per media
element" limitation, for the sake of simplifying the implementation. Without
such a restriction, we have a "cascade" of fallbacks as in <object>, and I can
foresee that this may be criticized as unduly complex.

This proposal replaces @longdesc while providing explicit alternatives for
<audio> <video> and <embed>. It is also compatible with any attempt that may
be made to simplify the content model of <object> on implementation grounds.

In legacy user agents, both the media element and its alternatives (or
alternatives) would be presented "side by side". User agents implementing
<alt> could be more flexible, however, in allowing the user to suppress
alternatives in cases where the media resource is rendered. Assistive
technologies and voice browsers could alert the user to the presence of the
alternative content in a uniform fashion, without relying on implicit
associations in the content of the document. Finally, accessibility
conformance checkers could verify the presence of the alternative content
programmatically, furthering the widely held objective of improving the
automated testability of accessibility requirements.

There may be other advantages to this proposal as well; the above are not
intended as exhaustive.
Received on Saturday, 4 August 2007 01:26:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:48 UTC