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

RE: CP, ISSUE-30: Link longdesc to role of img [Was: hypothetical question on longdesc]

From: John Foliot <john@foliot.ca>
Date: Wed, 21 Mar 2012 17:18:16 -0700
To: "'David Singer'" <singer@apple.com>
Cc: "'Sean Hayes'" <Sean.Hayes@microsoft.com>, <janina@rednote.net>, "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>, '"'"'xn--mlform-iua@målform.no'"'"' <xn--mlform-iua@xn--mlform-iua.no>, <rubys@intertwingly.net>, <laura.lee.carlson@gmail.com>, <mjs@apple.com>, "'Paul Cotton'" <Paul.Cotton@microsoft.com>, <public-html-a11y@w3.org>, <public-html@w3.org>
Message-ID: <027601cd07c1$49e43eb0$ddacbc10$@ca>
David Singer wrote:
> 
> (sketching furiously here)
> 
> <video…>
>   <track…>
>   <link rel="longdesc" href="…" />
>   <link rel="transcript" href="…" />
>   <div rel="alt" lang="cn-US">alternative text</div>
> </video>
> 

So, originally I had suggested child elements inside of the <video> element,
as I (and seemingly you too) subscribe to the basic XML dictate that
suggests that Elements are better than Attributes* - another endless debate
that has clogged the interwebs in the past. 

However, last fall at TPAC more than one browser engineer involved with
implementing <video> suggested that adding more children elements inside of
<video> was computationally heavy and that they would prefer not to do that
- attributes where easier to support and add support for. While I remain a
fan of elements, in this case I will take what I can get, and getting
support for attributes versus fighting for support for elements seemed
pointless to me, even though I acknowledge attributes weak points.

*
 - Elements are better than attributes; for semantics, javascript, css
 - If something needs to be referenced you should normally make it an
element, with an id attribute. 
 - If something represents a separate entity, make it an element: you might
want to add attributes later 


> Similarly the tracks could indicate timed accessibility alternatives
> via their "kind" label.

Ya, there was some discussion around extending the number of @kind values,
that got derailed and derided by some browser engineers (at least that is
what *I* recall). I believe that (Comcast? CableLabs?) had asked for either
more, or an extensible mechanism to reference more and that it was met with
resistance. We could perhaps again look at adding new @kind values:

  <track kind="transcript" src="">
  <track kind="description" src="">
  <track kind="posterdescription" src="">

If there were some indication of looking at those possibilities I would be
open to them.


> 
> And these are all useful for all users; a programmatic way to find the
> transcript, description, and short text benefit all boats.

I think keeping @alt and applying it to <video> is a strong pattern that has
years of understanding from even mainstream, garden variety developers - so
let's not mess with a good thing.  As for the programmatic associations -
that's code; what's clearly more important is support from User Agents

JF
Received on Thursday, 22 March 2012 00:19:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:31 UTC