Re: Marking up alternative versions of content

On Sun, Aug 05, 2007 at 01:28:02AM +0200, Sander Tekelenburg wrote:
 
> > I agree that MIMe types may be insufficiently expressive for this purpose.
> 
> Thinking about this some more, I suppose authors could use @title. Seems
> appropriate, no?
> con: no unified identifiers, so users will have to figure out what individual
> authors mean with for example title="caption".
> pro: no unified identifiers, so authors will have the freedom to describe
> types of alternatives that the spec didn't anticipate.
> pro: would allow authors to satisfy a user's need to know why an equivalent
> was provided
> con: does not solve the need to automaticaally dismiss certain types of
> equivalents. But possibly, when @title is used, an additional type attribute
> avdertising the MIME type would be good enough. A UA could then omit known to
> be unwanted file types from being presented, and for all other file types
> leave things up to the user to decide based on @title's advisory content.

Even if, as Rob has suggested, @type is extended beyond MIME media types,
there will surely be some alternatives that cannot be adequately characterized
by the @type values permitted in the spec. In such circumstances, your
proposal above is still needed, and hence it and Rob's suggestion are not
mutually exclusive.
 
> FWIW, it seems far too early to me to go into that ;) However, if we would
> have to end up with allowing only a single equivalent, it would have to be
> marked up text. (Or else HTML would fail to meet the "universality" (or
> "base accessibility") need and only satisfy specific ideal accessibility
> needs. See
> <http://esw.w3.org/topic/HTML/AccessibilityConsensus#head-b7bd18ab096371248721e683b16207aef740373d>
> for rationale.)

I agree, noting however that the marked up text could still include
hyperlinks to additional, alternative resources. 
> 
> I'm also not convinced that multiple equivalents would absolutely have to
> involve a cascade. While it would seem ideal, a flat list might be good
> enough. If so, and if a cascade is not realistically implementable, a flat
> list might be OK. (Think of how UAs let users select from alist of alternate
> Style Sheets, or from a list of RSS feeds.)

This is a good point. Such behaviour could be mandated by specifying that the
type of the element to which the FOR attribute of ALT refers must be one of
IMG, EMBED, AUDIO and VIDEO.

If a full hierarchy of alternatives were permitted, though, it could be
marked up by having each successive ALT element in the hierarchy referring, in
its FOR attribute, to its predecessor:
Schematically:
<embed [...] id="a">
<alt for="a" id="b"> [...]
<alt for="b" id="c"> [...]

where b is the fallback for a, and c is the fallback for b. Structurally, this
is somewhat analogous to a linked list.
> 
> > This proposal replaces @longdesc while providing explicit alternatives for
> > <audio> <video> and <embed>.
> 
> I'm not sure why you name @longdesc and not @alt, nor <img>. I was thinking
> <alt> could work for all those, and thus get us closer to a unified
> authoring mechanism:
> <http://esw.w3.org/topic/HTML/AccessibilityConsensus#head-5dfb39f27fc32ce627f52cbd17727188ecac300e>

This would indeed be desirable, and I would have put it in those terms if I
had properly separated the issue of providing alternatives from that of
deprecation: @alt is unlikely to be deprecated, as it is a required attribute,
heavily relied on in practice, and widely used in actual HTML documents.
However, it remains true that <alt> could serve as a substitute for both @alt
and @longdesc, with the TITLE attribute of <alt> replacing @alt, and its
content replacing @longdesc.
> 
> [...]
> 
> Yes, it might satisfy the vackwards compatibility requirement in that
> respect. OTOH, I imagine that during a transitionperiod where still many
> such legacy UAs are in use, authors will be bothered by 'forcing'
> equivalents into users.
> 
> I've been thinking that possibly CSS applies here. Authors (and users) could
> set <alt> to display:none. But a HTML5 UA would then need to understand to
> override in 2 ways: [1] the existence of <alt> should trigger the indicator
> that an equivalent exists, even when it is set to display:none [2] when the
> user selects that equivalent, the UA should understand that to mean that
> display: none must be overridden
> 
> This would appear to be similar to the user selecting an alternate Style
> Sheet, so might not be that enormous a burden to implement in UAs.

These are apt observations. My impression from accessibility-related
discussions over a number of years is that there is a significant constituency
within the Web content authoring community who would insist on hiding
alternatives used primarily by non-visual user agents from users of visual
user agents, unless the latter specifically configure their UAs to display
them. This position is the diametric opposite of that according to which
"invisible" metadata should be avoided.

My response is to argue that the existence of such divergent views counts in
favour of marking up alternatives explicitly, so that they can be hidden, or
presented, according to a combination of the author's and the user's
preferences, with the latter's needs and preferences of course being
ultimately determinative, as expressed in user agent configuration settings,
for example.
> 
> > User agents implementing <alt> could be more flexible, however, in
> > allowing the user to suppress alternatives in cases where the media
> > resource is rendered.
> 
> I think I simply don't understand theat sentence :) Could you say it in
> different words?

The idea is that, with an explicit association, it becomes possible to hide or
render alternatives selectively, according to the needs of the user as
declared in the user agent's configuration settings. Implicit associations do
not allow this, as the UA has no means of reliably determining what the
0alternatives are, or even of discovering that there are any.

Received on Sunday, 5 August 2007 11:30:28 UTC