W3C home > Mailing lists > Public > public-html@w3.org > March 2012

Re: ISSUE-194: full-transcript - Chairs Solicit Alternate Proposals or Counter-Proposals

From: Charles McCathieNevile <chaals@opera.com>
Date: Thu, 15 Mar 2012 15:50:18 +0100
To: "Sean Hayes" <Sean.Hayes@microsoft.com>, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Sam Ruby" <rubys@intertwingly.net>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.wa7vh4enwxe0ny@widsith-3.local>
On Thu, 15 Mar 2012 12:27:53 +0100, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> This is a good discussion.

Yep.

> On Thu, Mar 15, 2012 at 9:01 PM, Sean Hayes <Sean.Hayes@microsoft.com>  
> wrote:
>> I am not sure that these are necessarily the same thing at all. A  
>> transcript is IMO a static untimed merged representation of the  
>> information in in the caption and description tracks. A longdesc would  
>> probably be something more along the lines of a synopsis or précis. I  
>> think we need mechanisms that can handle both of these use cases.
>
> A summary is metadata and more than the sighted get if it's hidden in
> a such a field.

That depends. You don't have to be blind to get the longdesc for images  
 from Opera, even if it is sitting on another page. Indeed, curently in  
Opera sighted people have more ways than blind people to get value out of  
longdesc. I don't think that is a problem either way (although more  
generally we should be doing better for blind users).

> It would be a problem if we encouraged such
> publication approaches. Such text should be recommended to be
> published as on-page text and referenced with aria-describedby.

Not necessarily. There is a deep issue I have with ARIA, about claiming  
that it is only for "assistive technology" and thereby *assuming* it won't  
be implemented or wanted as native functionality in browsers. I think this  
assumption is demonstrably wrong (among other things a lot of aria  
functionality was developed to run directly in browsers).

>> I agree that it makes sense to wait and see how the discussion on  
>> generic 'off page text' pans out; it might be for example that we end  
>> up with both an attribute and an element e.g. @longdesc and <longdesc>  
>> (following the precedent of @src and <source>) where the latter admits  
>> a richer set of adornments, possibly including some sort of role  
>> attribute which can distinguish between a transcript and a synopsis,  
>> amongst other uses for off-page text.
>
> Do I understand correctly that this is a suggestion to allow several
> long description documents to be associated to a video? Do you have
> use cases? Why would video need something like this an no other
> element?

I don't think video is the only element that might need this, but I think  
Sean provides, above, a use case for at least two different long  
description documents...

cheers

-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Thursday, 15 March 2012 14:50:58 GMT

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