Re: Equivalents (was Re: Multilanguage alt/title)

At 23:09 -0700 UTC, on 2007-08-29, Maciej Stachowiak wrote:

> On Aug 29, 2007, at 8:35 PM, Sander Tekelenburg wrote:

[... <http://santek.no-ip.org/~st/tests/object/>]

> "image/*" is not a known MIME type, indeed I am not sure if it is even
> a legal type. It seems pretty simple to omit the type instead of using
> an illegal type, which likely makes us think we can't handle the
> content.

Yeah, maybe "image/*" is not a MIME type authors are likely to use. But just
plain "image" is, and has the same effect on Safari 2.0.4. (Just added to the
same test page.)

> In the long run the right thing to do is to ignore the type attribute
> and choose how to handle the content based on the server-reported
> return type, which I guess is what Firefox is moving to.

Yeah, that might be better (assuming the HTTP Content-Type can be trusted).
As a bonus, that would do away with the unfortunate situation that currently
@type is either normative or mereley advisary, depending on the element.

Completely ignoring @type would seem to go too far though. It could still be
useful as advisory information (in ways as mentioned in
<http://esw.w3.org/topic/HTML/ABetterAlt> and
<http://www.euronet.nl/~tekelenb/WWW/userfriendlierhyperlinks/> for instance).

[... <video>/<audio>fallback]

> <video type="video/mp4" src="lolcat.m4v">
> <object type="video/mp4" data="lolcat.m4v">
> ... text equivalent goes here, if needed ...
> </object>
>   </video>
>
> However, a video file may have optional caption tracks and/or
> descriptive audio, so a text equivalent may not be necessary for
> accessibility.

A text equivalent will always be necessary for universality.

That aside, nesting of objects has the serious downside that it forces
authors to force a specific fallback order upon the user. I suspect that your
announced proposal means to solve that for <audio>/<video>. If so, it
wouldn't be so bad if <object> would not provide that solution, *if* <object>
would be for legacy UAs only. That might in fact be good, as it would show a
clear benefit to authors to use <audio>/<video>, and for users to upgrade to
HTML5 UAs. However, that would still leave us with images... So either
<object> would need to be upgraded to the same solution (so authors can use
it for images), or we're back at the suggestion to add <picture> to the
<audio>/<video> family.

Another problem with having <audio>/<video> rely on an embedded <object> to
provide textual equivalents is that we will be stuck with thet construct
forever that way. Even by the time 'every' UA supports <audio>/<video>,
authors would still have to add <object> just to provide a textual
equivalent. I don't think we should steer towards that future.

[... announced proposal for <audio>/<video> accessibility]

> Our current proposal is for <audio>/<video> based on the fact that
> they can already list multiple <source> elements.

Right, makes sense. I would expect textual equivalents to bepart of it too
though. And let's not forget the use case where multiple equivalents need to
be consumed side by side (such as a transcript of an audio file), not just as
alternates.

> [...] As such I don't think it would really apply to the other elements.
> I suppose one could
> image providing high-contrast versions of static images.

Sorry, I can't follow. Are you talking about providing images through
<audio>/<video>?

[... <embed/> as <object> fallback]

> I think we should define that when <embed> is nested in <object> and
> neither can be presented, the <object> element's fallback applies.

Yeah, that might work. If new elements like <audio>, <video>, etc. would
allow for 'rich' equivalents authoring, then it might be OK to let <object>
and <embed> remain the poorer legacy elements (that'll hopefully slowly be
phased out by authors).


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

Received on Thursday, 30 August 2007 14:43:33 UTC