Re: Marking up alternative versions of content

At 21:30 +1000 UTC, on 2007-08-05, Jason White wrote:

> On Sun, Aug 05, 2007 at 01:28:02AM +0200, Sander Tekelenburg wrote:

[... limiting to single equivalent would only satisfy universality]

> I agree, noting however that the marked up text could still include
> hyperlinks to additional, alternative resources.

Indeed.

>> 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.

Hm... I'm not sure I understand. Why would it have to be limited to those
specific elements, and why would it have to be limited to any specific
element at all?

> 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.

Hm... That's an interesting idea.

I'm not sure it would work though. It seems risky to rely on authors making
no mistakes. Consider for instance a subsequent edit, where an equivalent is
moved, removed or added. The author would have to change @for and @id for the
other equivalents as well then. With a wrong @for value an <alt> element
would essentially be teleported to another dimension. (And a single web page
might well have instances of non-text objects, each with multiple
equiavalents).

Btw, the risk of @for pointing to a non-existing id exists anyway. How could
that be handled? It seems simple to say that in that case the UA must render
the <alt> element, even if it is set to display:none. That would be a good
enough error recovery for users. But it might be too challenging for UAs?

>> > 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.

I'm not sure I agree with that last bit. I see @alt and @longdesc as a single
two-piece hack to overcome the unique problems of <img>. Each serves one half
of the same goal. A poor solution. <object> doesn't have either @alt or
@longdesc, because its content can be long or short, rich or poor. Its
alternate markup mechanism needs not be split into multiple parts.

Coming from that view, I'd think that the content of <alt> would replace both
@alt and @longdesc. With <alt>, there is no longer a need to think in terms
of <img>'s split fallback personality, and I think that would be very
healthy. So I'd say that <alt>'s @title should definitely *not* contain an
equivalent. It should contain *advisory information* about that particular
<alt>.

The only question then would be how authors should (be allowed to) cater to
legacy UAs. In a way, this automatically would:

<img id="blah" src="URL"><alt for="blah" type="text/html" title="marked up
textual equivalent">single marked up equivalent of whatever length is
appropriate</alt>

But would the connection between <img> and <alt> be explicit enough if the
<alt> element immediately follows the img element? Or would it be essential
that legacy UAs be fed a more explicit connection?

> @alt is unlikely to be deprecated, as it is a required attribute,

What would it mean if @alt and/or @longdesc are kept in HTML5? Would that not
discourage authors to use <alt>? Would it not make some authors, trying to
cater for legacy UAs, do stuff like this:

<img id="blah" src="URL" alt="short textual equivalent" longdesc="URL">
<alt for="blah" type="text/html" title="marked up text">single long or short
marked up equivalent</alt>

Which would result in multiple of the same (or actually not the same, due to
the split between @alt and @longdesc) equivalents in legacy UAs, *and* in
HTML5 UAs.

<blasphemy>
In short, unless I'm overlooking something, it would seem that if we would go
for <alt>, we would need to deprecate @alt and @longdesc. With <alt> they're
not needed and actually in the way. Let's give'm a nice burial ceremony and
move on.
</blasphemy>


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Sunday, 5 August 2007 13:50:31 UTC