Re: Draft Summary Doc for our Media Call Today

Dave,

a variant movie - do you have a suggestion for how to expose this in HTML?

I have started a discussion on multitrack API and I think that's where
we should continue, see
http://lists.w3.org/Archives/Public/public-html-a11y/2010Oct/0614.html.
It needs a JavaScript API for those tracks that come from within the
resource (the "low-hanging fruit"), but also for the external tracks
(for which the markup question needs to be solved).

I would really appreciate more input/opinions on that thread. Thus far
we have not come to an agreement on the best technical way for it.

Cheers,
Silvia.


On Thu, Dec 2, 2010 at 9:45 AM, David Singer <singer@apple.com> wrote:
> I think it's premature to 'adopt' either.  I am sure it's a mistake to try to solve problems such as trying to time speech synthesis to the video;  if someone wants to do audio-description of video, I expect they'd do it by authoring a variant movie.  This is the low-hanging fruit, and it continues to frustrate me that we reach for a few pieces of high fruit and do not set in place simple structures that will enable many people to do simple and effective things for accessibility.
>
>
> On Dec 1, 2010, at 14:21 , Sean Hayes wrote:
>
>> One of my concerns however is that in meeting the requirements checklist you have described a number of features that are clearly not SRT and I at least have not seen any implementation of. If plain SRT is considered an implementation, and WebSRT is chosen as the format; then implementers may in fact just do plain SRT, and not add any of those features and thus the user requirements will not be met. In addition how many of these proposed features are actually agreed to by the WebSRT development group? Again if they are not accepted we face a similar situation.
>>
>>
>> -----Original Message-----
>> From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Silvia Pfeiffer
>> Sent: 01 December 2010 22:09
>> To: Janina Sajka; HTML Accessibility Task Force
>> Subject: Re: Draft Summary Doc for our Media Call Today
>>
>> Some comments on WebSRT:
>>
>> "with little-to-no current implementation"
>> That's not quite true. You could call all SRT implementations an implementation, and thus it is integrated in many existing commercial and non-commercial tools and tool chains, including YouTube, JWPlayer, in Ogg through the Kate track, in Matroska (thus easily in WebM) through SRT track, in media players such as VLC, MPlayer, etc. New implementations in JavaScript also already exists, see e.g.
>> http://yayquery.github.com/jquery-singalong/ .
>>
>> "Does not support specification of a means to tell the player to stop the video and wait for the end of the speech synthesis. "
>> That is an equal problem between TTML and WebSRT and has to be solved universally.
>>
>> Regards,
>> Silvia.
>>
>>
>> On Thu, Dec 2, 2010 at 8:59 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
>>> Some comments:
>>> "XML-based nature raises concerns with regard to name-spacing, draconian error handling, etc"
>>> I still have yet to find out what precisely is the problem here, so I don't actually see this as a Con, however for those that do, I will also point out that TTML is actually formally defined in terms of a reduced XML infoset, thus it would be entirely possible to write a lenient non-namespace aware tag soup parser that produced this infoset. IMO doing so would not be in anyone's best interests but the option remains.
>>>
>>> "As currently specc'd cannot be styled with CSS"
>>> Cannot is not accurate. CSS can style any XML format. What you mean is that CSS is not currently very well set up to style a dynamically changing DOM, however it can be applied to the method documented at http://www.cwmwenallt.com/ttml/TTMLmapping.htm and utilize the host page's CSS to style to override the TTML inline style. While we are talking about style I'll also point out here that WebSRT has to rely on a future version of CSS being applied from the host page. I think that is a definite Con.
>>>
>>> "Will require a profile crafted to address what is perceived as an overly verbose and complex specification"
>>> Well I would compare it to the HTML5 spec before anyone starts calling it overly verbose or complex. There is the opportunity to write a profile if need be for sure, however given that I was able to write a complete mapping in JS in just over a week, I personally think the full profile will be fine.
>>>
>>> "Does not support hierarchical structure navigation"
>>>  - I have added an example in the checklist, so this should be removed.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: public-html-a11y-request@w3.org
>>> [mailto:public-html-a11y-request@w3.org] On Behalf Of Janina Sajka
>>> Sent: 01 December 2010 21:33
>>> To: HTML Accessibility Task Force
>>> Subject: Draft Summary Doc for our Media Call Today
>>>
>>> Colleagues:
>>>
>>> The following was prepared by John for our Media Subteam call today:
>>>
>>> http://www.w3.org/WAI/PF/HTML/wiki/TextFormat_Pros_Cons_Overview#Summa
>>> ry_o
>>>
>>> It is hoped this draft will give us a head start on finalizing a summary report that can be shared with the WG.
>>>
>>> Janina
>>>
>>>
>>> --
>>>
>>> Janina Sajka,   Phone:  +1.443.300.2200
>>>                sip:janina@asterisk.rednote.net
>>>
>>> Chair, Open Accessibility       janina@a11y.org Linux Foundation
>>> http://a11y.org
>>>
>>> Chair, Protocols & Formats
>>> Web Accessibility Initiative    http://www.w3.org/wai/pf World Wide
>>> Web Consortium (W3C)
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
>
>

Received on Thursday, 2 December 2010 00:07:04 UTC