Re: Format Requirements for Text Audio Descriptions (was Re: HTML5 TF from my team)

Sorry, I seemed to make duplicate posts at the same time due to a trouble 
of my email client.



Masatomo Kobayashi/Japan/IBM wrote on 2010/05/27 06:50:07:

> Hi Silvia,
> 
> Thank you for considering my input.
> Generally it looks fine as it is, being consistent with our experience.
> 
> Just a few comments:
> 
> The requirements regarding TTS overflowing might be able to be 
> partly introduced
> in the section 2.1 because it occurs just depending on client-side 
> TTS settings,
> and 'extending' is not the only means to address it as mentioned in 
EAD-6.
> It would affect video creation in a different way from 
> intentionally-extended AD
> (traditional EAD), which would still be extended in human-narrated AD.
> So the separation of EAD types (traditional EAD and the overflow case) 
would
> make the requirements structure clearer.
> Though I am not sure which the best place to put them in is, EAD-5 and 6 
seems
> not a specific requirement to EAD.
> 
> Also, the last item in the paragraph regarding textual EAD (i.e., A 
visually-
> complicated scene...) might not fit in this place because actually it is 
a
> traditional reason of EAD.
> 
> Regards,
> Masatomo
> 
> Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote on 2010/05/26 
16:58:30:
> 
> > Hi Masatomo,
> > 
> > I have just added an extended set of requirements to the "extended
> > audio descriptions" requirements collection that this group has
> > started on the wiki, see
> > http://www.w3.org/WAI/PF/HTML/wiki/
> > Media_Accessibility_Requirements#Extended_audio_description
> > .
> > 
> > I would value your input into that requirements list.
> > 
> > Thanks,
> > Silvia.
> > 
> > 
> > On Fri, May 7, 2010 at 2:37 AM, Masatomo Kobayashi <MSTM@jp.ibm.com> 
wrote:
> > > My comments on extended captions and Speech CSS are inline below.
> > >
> > > Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote on 2010/05/05 
09:11:08:
> > >
> > >> Thinking about it in more depth, we may even want to use such an
> > >> attribute on captions and subtitles. It would indicate what will
> > >> happen if caption elements overlap into the next caption text cue, 
ie.
> > >> just display both (which would be the default) or clip the cue.
> > >> Pausing the video probably doesn't make sense for caption text.
> > >
> > > Oops, I have never deeply thought about captions.
> > > I agree that we could use that attribute to handle overlapping 
captions.
> > >
> > > I think "extended caption" in Geoff's comment is also interesting.
> > > In contrast to extended audio descriptions, a boolean flag will be 
needed
> > > for each "extended" caption element?
> > > The duration of a caption must be explicitly specified by the 
> author (so we
> > > cannot set the same begin/end time to indicate it is 
"extended")while that
> > > of an audio description is actually determined by the TTS engine.
> > >
> > >> That would be one way to support it. Do you know if Web browsers
> > >> support SSML natively?
> > >>
> > >> Also, there is Speech CSS (see http://www.w3.org/TR/css3-speech/),
> > >> which seems to provide for the same functionality. Have you
> > >> experimented with Speech CSS? Do you know if TTS engines support 
it?
> > >
> > > According to documents, Opera supports Speech CSS and a small 
> part of SSML.
> > > Also Fire Vox provides support for Speech CSS.
> > > But unfortunately they did not work well on my PC, so I have not 
actually
> > > used those features.
> > >
> > > If Seeech CSS is chosen, the problem will be with which format 
(instead of
> > > srt) to use to mark up the external text resource to be described by 
the
> > > CSS.
> > >
> > > We might need to check SSML/Speech CSS features of Web browsers, 
screen
> > > readers, and TTS engines to explore the possibility of rich textual 
audio
> > > descriptions.
> > >
> > > Regards,
> > > Masatomo
> > >