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

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
> >