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

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

From: Sander Tekelenburg <st@isoc.nl>
Date: Thu, 30 Aug 2007 17:09:48 +0200
Message-Id: <p06240642c2fc86d13d1e@[192.168.0.101]>
To: public-html@w3.org

At 16:57 +1000 UTC, on 2007-08-30, Marghanita da Cruz wrote:

[...]

>  From a browsing perspective, Text equivalent would be helpful in deciding
> whether to download the video or not.

Disagreed. That would be mixing up the concepts of "advisory information" and
"equivalents". Sure, when no advisory information is available, then in
practice a textual equivalent would have to serve that purpose. But that's
similar to UAs reading the href attribute just because no @alt is available.
We should not aim for a situation in which equivalents need to be authored to
also be advisory. It would only lead to even more authors abusing "alt text"
for advisory information.

Whether it is useful to download a video or not should be decidable upon
context and explicit advisory information (provided through @title and @type,
for instance).

> Is streaming or download a function of the server/filetype or should that be
> specified in the filetype.

FWIW, I have no idea what "server/filetype" and "filetype" mean here.

> It would also be useful to be able to specify a choice of
> languages/mono/stereo/video quality (preview, mobile phone vs home theatre)
>etc
> in associated audio tracks, text descriptions
> and maybe even sub-titling (in multiple languages/scripts).

I think the proposed <alt> (see <http://esw.w3.org/topic/HTML/ABetterAlt>)
could handle all that. I've added a note about @lang for this. (Note though
that there is still dicussion about whether multilingual content is to be in
the scope of this WG.  See the Design Principles discussion.)

[...]

> How will captioning for hearing rather than visually impaired be supported.
>In
> the TV broadcast arena there are currently competing standards for
>captioning.

The simplest would probably be 'burned in' captions and subtitles. But a
single video file with multiple separate caption and subtitles files would be
more elegant, cost less bandwidth, and be cheaper to author. This would also
be needed to allow users to define a font and font size for captions and
subtitles. So yes, perhaps we need to ensure that captions and subtitles can
be provided separately.

(Btw, captions aren't useful only for deaf people. They can also be useful to
users with excellent hearing in for instance situations where the sound would
bother other people.)


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
Received on Thursday, 30 August 2007 15:13:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:04 GMT